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SECTION  1 


INTRODUCTION 


1.1  SUMMARY 

This  volume  describes  the  development  of  the  Strategic/Tactical  Optical  Disk  System  Jukebox  (S/ 
TODS  Jukebox)  by  Lockheed  Martin  Communications  Systems  for  the  Air  Force  Materiel  Com¬ 
mand’s  Rome  Laboratory,  under  Phase  2  of  contract  F30602-89-C-008.  The  purpose  of  Phase  2 
was  to  design,  build,  and  test  a  10  disk  ruggedized  deployable  Jukebox  based  on  the  S/TODS  Air¬ 
borne  Optical  Disk  Recorder  and  Media  previously  developed  under  Phase  1. 

The  single  disk  S/TODS  Advanced  Development  Model  (ADM)  Airborne  Recorder  and  the  Media 
development  (Phase  1)  is  covered  in  Volume  1  of  this  report.  The  equipment  developed  in  Phase 
1  was  utilized  in  Phase  2.  The  modifications  required  to  convert  the  Airborne  disk  drive  for  Jukebox 
operation  are  covered  in  this  volume. 

The  Jukebox  incorporates  features  such  as  a  rugged,  modular  design  for  quick  easy  deployment  set¬ 
up  and  tear  down,  dual  picker  robotics  for  fast  cycle  time,  and  an  easily  interchangeable  disk  cache 
for  rapid  data  access  in  very  large  capacity  applications.  System  capacity  is  120  GBytes  per  10  disk 
cache.  Control  and  data  interface  is  standard  SCSI  2. 

The  Jukebox  was  integrated  and  tested  with  a  Sun  Workstation  and  with  the  Air  Force  Mission  Sup¬ 
port  System  (AFMSS)  at  the  Lockheed  Martin  facility.  At  the  Air  Force’s  Special  Operations  Com¬ 
mand  ( AFSOC)  the  Jukebox  was  integrated  and  demonstrated  running  as  a  standard  SCSI  peripheral 
on  the  Special  Operations  Forces  Planning  and  Rehearsal  (SOFPARS)  mission  planner. 

Hierarchical  Storage  Management  (HSM)  software  running  on  a  Sun  workstation  was  integrated 
with  the  S/TODS  Jukebox,  providing  automatic,  transparent  management  of  the  10  disk  cache. 

1.2  SCOPE 

This  volume  covers  the  analysis,  design,  fabrication,  integration,  and  test  results  of  the  development 
of  the  S/TODS  Jukebox. 

1.3  BACKGROUND 


1.4  PROGRAM  OVERVIEW 

This  program  was  performed  in  two  consecutive  phases.  Phase  1 ,  covered  in  Volume  1  of  this  report, 
developed  the  airborne  single  disk  S/TODS  Advanced  Development  Model  (S/TODS  ADM)  and 
the  custom  14”  media.  Phase  2,  covered  in  this  volume,  developed  a  10  disk  deployable  Jukebox 
based  on  the  recorder  and  media  from  the  previous  phase.  The  airborne  recorder  development  built 
on  the  results  of  the  Durable  I  and  Durable  n  optical  disk  programs  (see  RADC-TR-86-82  and 
RADC-TR-88-209),  where  key  risk  areas  were  evaluated  and  system  trade-off  studies  were  per¬ 
formed. 
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1.4.1  Airborne  Phase 

A  high  performance  optical  disk  recorder  for  use  in  Scientific  and  Technical  (S&T)  Aircraft  was 
designed,  built  and  tested  in  Phase  1  of  this  program.  Custom,  14  inch  diameter,  rewritable  magne¬ 
to-optic  media  was  developed  under  subcontract  by  3M.  Analysis  and  design  began  in  December, 
1988.  The  recorder  demonstrated  successful  operation  under  stressful  conditions  during  September 
1993  flight  tests  on  an  RC-135  aircraft.  The  disk  drive  operated  without  error  through  aircraft  ma¬ 
neuvers  including  60  degree  bank  turns,  takeoff  and  landings,  and  tactical  descents.  Acceptance  test 
was  completed  in  February  1994.  Volume  1  of  this  report  covers  all  these  efforts  in  detail. 

1.4.2  Jukebox  Phase 

Following  the  Airborne  phase,  a  10  disk  Jukebox  version  of  the  S/TODS  recorder  was  designed, 
built,  and  tested.  Design  was  begun  in  September  1993,  PDR  was  held  in  December  of  that  year. 
CDR  of  the  mechanical,  electrical  and  software  designs  was  held  in  May,  1994.  Build  began  with 
the  frames  and  robot  mechanism  in  early  1994,  and  continued  with  the  electronics  in  mid  year.  Elec¬ 
tronic  modules  and  software  integration  began  in  November  1994,  along  with  the  necessary  modifi¬ 
cations  to  the  S/TODS  disk  drive  for  Jukebox  operation. 

A  major  interim  demonstration  milestone  in  Febniary  1995  showed  operation  of  the  Jukebox  robot 
mechanism  with  the  S/TODS  disk  drive  assembled  on  a  lab  bench.  Following  the  demonstration. 
Jukebox  system  integration  was  completed  in  May  1995.  Integration  and  testing  with  a  Sun  worksta¬ 
tion,  the  AFMSS  mission  planning  system,  and  Metior  Flierarchical  Storage  Manager  was  done 
through  summer  and  fall  1995,  cumulating  in  a  demonstration  of  the  Jukebox  system  at  the  Air  Force 
Special  Operations  Command  (AFSOC)  in  January,  1996. 


1.5  GENERAL  DESCRIPTION  OF  THE  EQUIPMENT 

The  S/TODS  Jukebox  is  shown  in  Figure  1.5-1. 


1.5.1  General  Performance  Specifications 

The  specifications  of  the  S/TODS  Jukebox  are  summarized  in  Table  1.5. 1-1. 

TABLE  1.5. 1-1  S/TODS  Jukebox  Performance  Specifications 


SPECIFICATION: 
Interface  : 
Mounting: 
Size: 
Weight: 
Power: 
Recording  Media: 
Individual  Disk  Capacity: 
Data  Transfer  Rate  (Burst): 
Data  Transfer  Rate  (Continuous): 

Bit  Error  Rate  (BER): 
Disk  Storage: 
Temperature: 

Shock: 


VALUE 
SCSI  2 
Stand  Alone 

57”  length,  32”  width,  45”  height 
485  lbs  (deployed) 

120  VAC,  50/60  Hz,  Kb,  4  A  avg,  6  A  max 
Qty  10,  14  inch  erasable  disks,  (expandable) 
6.0  Gigabytes/side,  2  sided  disk 
10  Mbytes/s 
0  to  25  Mbits/s 

<  1  X  10-11 

in  standard  disk  carriers  in  cache 
0  C  to  -1-40  C  operational 
^0  C  to  +68  C  Transit  and  Storage 
15  inch  drop 
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Figure  1.5-1  S/TODS  Jukebox 


1.5.2  The  S/TODS  Jukebox  Equipment 

The  Jukebox  is  comprised  of  the  Robotics  Unit  (RU)  and  the  Support  Rack  (SR)  cases.  The  two 
cases  are  detached  for  deployment  in  easily  managed  pieces.  The  RU  contains  the  disk  accessing 
mechanism  providing  movement  of  the  optical  disks  between  the  disk  storage  Cache  and  the  disk 
drive.  The  disk  drive  is  composed  of  the  Disk  Drive  Unit  (DDU)  and  the  Electronics  Unit  (EU), 
both  of  which  are  housed  in  the  SR  along  with  the  Disk  Cache  and  Jukebox  control  electronics.  The 
equipment  in  the  operational  configuration  is  shown  in  Figure  1.5.2-1. 

1.5.3  The  Optical  Disk  Drive  Equipment 

The  S/TODS  ADM  airborne  optical  disk  drive  was  developed  in  Phase  1  and  covered  in  Volume  1 
of  this  report.  This  high  performance  rewritable  recorder  incorporated  many  advanced  features  such 
as  dual  write  lasers  with  separate  read  beams  for  fast  data  transfer  and  real  time  verification;  25 
Mbit/s  continuous  transfer  rate;  and  very  small  written  feature  size  for  12  GByte  capacity  per  double 
sided  disk.  Required  modifications  for  Jukebox  operation  are  covered  in  this  volume. 

1.5.3. 1  Modifications  for  Jukebox  Operation 

Modifications  to  the  disk  drive  were  necessary  for  Jukebox  operation.  Both  the  DDU  and  the  EU 
mounting  was  changed  from  the  airborne  configuration  rack  mount  to  a  drawer  mount  configura¬ 
tion.  The  DDU  required  changes  to  the  disk  loading  mechanism  to  allow  use  with  the  robotics  mech- 


anism  of  the  Jukebox.  Software  changes  were  made  to  the  EU  for  coordinating  operations  with  the 
robotics  controller,  and  the  drive  was  converted  from  SCSI  1  to  SCSI  2  interface. 

1.5.4  Media 

14  inch  diameter  custom  magneto-optic  media  was  developed  under  subcontract  by  3M  in  Phase 
1  of  this  program,  and  is  described  in  Volume  1  of  this  report.  Additional  work  on  media  perfor¬ 
mance  and  utilization  was  done  in  Phase  2  and  is  covered  here.  Ten  disks  are  housed  in  standard 
14”  carriers  in  the  Disk  Cache  of  the  Jukebox.  The  double  sided  disks  store  6  GByte  per  side  and 
are  rewritable. 

1.6  HOST  INTEGRATION 

The  Jukebox  was  interfaced  via  SCSI  2  as  a  storage  peripheral  to  a  number  of  Host  system  configura¬ 
tions  and  software  packages. 

1.6.1  SCSI  2  Interface 

The  Jukebox  command  and  data  interface  is  via  SCSI  2.  Modifications  were  made  to  the  disk  drive 
to  convert  from  SCSI  1 ,  used  in  the  airborne  configuration.  A  standard  VME  SCSI  2  controller  mod¬ 
ule  was  purchased  and  installed  in  the  EU.  Custom  software  for  the  Jukebox  was  written  for  this 
module. 
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The  Jukebox  conforms  with  the  SCSI  2  specifications  for  a  direct  access  device  and  for  a  medium 
changer  device.  All  mandatory  commands  are  supported.  In  addition,  a  number  of  optional  com¬ 
mands  necessary  for  compatibility  with  the  Sun  Workstation  and  purchased  software  packages  are 
also  supported.  Refer  to  the  Jukebox  ICD  for  details  of  this  interface  and  supported  commands. 

1.6.2  Sun  Workstation 

Interface  with  a  Sun  SPARC  10  Workstation  was  accomplished  under  both  SunOS  and  Solaris  oper¬ 
ating  systems.  File  systems  were  created  on  selected  disk  sides.  The  Jukebox  was  then  mounted 
as  a  normal  UNIX  file  system,  appearing  as  a  standard  hard  drive  to  the  filesystem  software  and  the 
operator.  A  software  tool  was  developed  for  use  with  the  Sun  Workstation.  This  tool  permits  the 
operator  to  issue  Jukebox  disk  movement  commands.  Disk  load  and  store  commands  are  entered 
using  the  mouse  in  the  graphical  user  interface  (GUI)  version  or  from  a  command  tool  in  the  com¬ 
mand  line  version. 

1.6.3  Air  Force  Mission  Planning  Systems 

A  SCSI  external  hard  drive  was  loaded  with  the  Air  Force  Mission  Support  System  (AFMSS)  soft¬ 
ware  by  Lockheed  Sanders,  the  vendor.  This  system  runs  on  a  Sun  workstation  and  is  used  by  pilots 
for  planning  flights.  The  large,  random  access,  map  database  required  for  planner  operation  is  a  typi¬ 
cal  Air  Force  application  of  the  S/TODS  Jukebox.  In  the  Camden  facility,  the  Jukebox  was  inte¬ 
grated  with  AFMSS  in  a  standalone  demonstration  system  consisting  of  the  Jukebox,  external  hard 
drive,  and  a  Sun  Sparc  10  workstation. 

Following  integration  of  the  stand  alone  system,  the  Jukebox  was  shipped  to  the  Air  Force  Special 
Operations  Command  (AFSOC)  at  Hurlburt  Field,  Florida  and  integrated  with  the  Special  Opera¬ 
tions  Forces  Planning  and  Rehearsal  System  (SOFPARS).  SOFPARS  is  a  deployable  mission  plan¬ 
ner  running  the  AFMSS  software. 

1.6.4  Metior  HSM 

The  S/TODS  Jukebox  was  integrated  with  the  Metior  -  Hierarchical  Storage  Management  (HSM) 
software.  The  Metior  software  is  a  commercial  package,  supplied  by  ANT  Inc..  The  Metior  soft¬ 
ware  is  nm  on  a  Sun  Workstation  and  interfaces  the  associated  Unix  file  system  with  the  Jukebox 
in  such  a  way  that  disk  move  management,  file  migration  from  the  Sun  hard  drive  to  the  Jukebox, 
and  file  retrieval  from  the  Jukebox  is  provided  transparently  to  the  user.  This  system  potentially 
makes  the  Jukebox  appear  to  the  user  as  a  single  120  GByte  hard  drive. 
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SECTION  2 


JUKEBOX  ANALYSIS 


2.1  INTRODUCTION 

This  section  summarizes  the  system  analysis  performed  prior  to  the  detail  design  of  the  Jukebox  sys¬ 
tem.  System  architecture  rational  and  preliminary  design  choices  are  included.  Design  was  based 
on  the  Statement  of  Work  for  Tactical  Optical  Disk  Systems  (TODS )  PR  NO.  1-9-4266  dated  Decem¬ 
ber  27  1988,  Amendment  to  Statement  of  Work  PR  NO.  1-3^092  dated  May  25  1993,  and  issues 
identified  by  Lockheed  Martin  during  analysis. 


2.2  SIZE 

The  size  of  the  Jukebox  is  driven  by  the  volume  of  the  disk  drive  and  disk  storage  cache,  the  size 
of  a  robot  capable  of  translating  and  rotating  the  14”  disks,  and  the  ruggedness  and  shock  isolation 
necessary  for  the  transit  and  deployment  requirements. 

2.2.1  Volume 

The  volume  specification  was  the  equivalent  of  one  standard  19”  equipment  rack.  This  requirement 
was  met  with  equipment  dimensions  in  the  deployed  configuration  of  57”  length  X  32”  width  X  45” 
height.  Approximately  one  half  of  the  volume  is  required  for  the  robotic  mechanism,  which  needs 
free  space  to  translate  and  rotate  disks.  The  second  half  of  the  volume  is  the  disk  drive  Electronics 
Unit  (EU),  the  Disk  Drive  Unit  (DDU),  and  the  disk  storage  cache.  These  three  items  are  packaged 
in  a  stacked  configuration.  This  dictates  the  minimum  height  of  the  Jukebox.  The  EU  is  located 
on  the  bottom,  the  DDU  in  the  middle,  and  the  cache  is  on  top.  The  DDU  and  cache  are  adjacent 
so  as  to  minimize  translation  distance.  The  remaining  miscellaneous  smaller  components  such  as 
the  control  electronics,  power  supply,  and  cooling  components  were  located  in  the  areas  left  avail¬ 
able  by  the  described  configuration. 

2.2.2  Weight 

Specified  maximum  weight  was  600  lbs  in  the  deployed  configuration,  with  a  500  lb  goal.  The  goal 
was  not  met,  with  the  final  weight  585  lbs.  The  ruggedness  requirements  for  transport  tend  to  drive 
the  weight  upward,  see  Transport,  Section  2.3.1. 

2.2.3  Deployment 

A  major  design  criteria  was  the  transportability  specification.  The  unit  must  be  broken  down  into 
subunits  suitable  for  two  man  lift.  To  meet  this  requirement  the  Jukebox  is  designed  to  split  into  two 
subunits,  the  Robotics  Unit  (RU)  case  and  the  Support  Rack  (SR)  case.  The  disk  drive  EU,  DDU, 
and  the  disk  Cache  are  easily  removed  from  the  Support  Rack  and  are  packed  and  transported  in 
individual  shipping  containers.  Setup  and  breakdown  are  accomplished  by  2  people  in  under  30 
minutes,  without  tools.  Jukebox  structures  are  self  aligning  and  are  secured  by  hand  operated 
latches.  On  power  up,  the  Jukebox  mechanisms  perform  a  brief  sequence  of  simple,  automatic  self¬ 
alignment  operations.  No  manual  alignment  of  mechanisms  is  required  after  shipment  and  setup. 
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The  two  man  lift  weight  requirement  was  exceeded  on  the  RU  design,  at  234  lbs  as  shipped.  This 
is  due  to  the  ruggedness  requirements  of  RU  the  structure.  Casters  were  added  to  allow  one  or  two 
people  to  easily  move  the  RU  and  SR  cases,  separated  or  mated,  or  flip  them  upright  from  a  prone 
transport  position.  Three  men  are  recommended  to  lift  the  units  if  it  becomes  necessary  to  carry  them 
across  rough  terrain. 


2.3  ENVIRONMENT 

The  major  environment  specifications  driving  the  design  involve  the  ruggedness  requirements  for 
transport.  Temperature,  humidity,  and  pressure  specifications  were  met. 

2.3.1  Transport 

A 15”  drop  shock  and  0.04  G^/Hz  vibration  non-operational  specifications  necessitated  internal  iso¬ 
lators  and  strong,  stiff  cases  and  frames  for  the  SR  and  RU.  Wire  rope  isolators  were  chosen  for 
unchanged  damping  characteristics  over  the  temperature  range.  The  two  units  are  designed  with  all 
components  mounted  on  internal  aluminum  tube  frames  designed  for  50G  shock.  The  frames  then 
mount  on  8  wire  rope  isolators  to  the  corners  of  the  cases.  Analysis  showed  an  acceptable  transmitted 
shock  of  40G  for  a  15”  drop  in  any  axis.  The  size  of  the  cases  was  determined  by  the  sway  space 
requirements  of  the  isolators  for  the  shock  and  vibration  specifications,  given  frames  holding  the 
robot  and  drive  components. 

Transport  and  storage  temperature  range  specification  is  -40  to  +68  °  C.  The  drive  meets  this  speci¬ 
fication,  and  all  Jukebox  components  were  selected  to  meet  this  range. 

2.3.2  Operational 

The  Jukebox  is  designed  for  operation  in  a  fixed  location,  such  as  a  mobile  shelter.  The  specified 
Temperature  range  is  0  to  40°  C.  The  drive  meets  this  specification,  and  all  Jukebox  components 
were  selected  to  meet  this  range.  To  allow  operation  in  dirty  environments  the  cases  are  sealed  by 
gaskets  when  mated  in  the  deployed  configuration.  The  cases  and  seals  isolate  the  interior  and  keep 
the  disks  and  the  disk  drive  clean. 

2.3.2. 1  Cooling 

The  disk  drive  electronics  unit  is  cooled  by  convection.  The  disk  drive  optics,  disk  drive  mechanism, 
and  robotics  unit  are  cool  by  a  combination  of  convection  and  radiation.  The  drive  EU  utilizes  exter¬ 
nal  ambient  air  via  inlet  and  exhaust  ducts  for  cooling.  The  ducts  are  provided  with  filters  for  dirt 
and  EMI  protection.  Small  amounts  of  dirt  will  not  affect  the  electronics.  So  that  the  disks  and  mech¬ 
anism  would  not  be  affected  by  a  dirty  ambient  atmosphere  the  cooling  air  for  the  drive  EU  is  kept 
separate  from  the  cooling  air  for  the  drive  and  robotics  unit.  Fans  in  the  sealed  internal  area  were 
designed  to  circulate  air  in  a  controlled  manner  through  the  remaining  components  and  along  the 
walls  of  the  cases,  providing  radiative  and  conductive  cooling.  Analysis  of  the  heat  dissipation 
showed  an  expected  internal  temperature  rise  of  5°  C.  This  was  verified  by  test. 


2.4  INTERFACE 

The  system  architecture  assigns  all  data  and  control  interface  to  the  SCSI  bus,  with  the  minimal  front 
panel  operator  control  requirements  for  power  and  selftest.  For  maintenance  control  and  detailed 
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fault  analysis  a  diagnostic  port  for  a  standard  terminal  is  provided.  A  laptop  PC  is  shipped  with  the 
Jukebox  for  fault  diagnosis  purposes. 

2.4.1  Control  and  Data  Interface 

Jukebox  disk  movement  commands  and  read/write  data  transfers  are  done  via  the  SCSI  2  bus.  The 
airborne  drive  used  the  older  SCSI  1  bus,  upgrading  to  SCSI  2  was  elected  for  increased  transfer  rate 
and  usage  of  the  SCSI  2  Move  Medium  command  set.  A  single  board  computer  module  was  pur¬ 
chased  and  software  written  to  handle  this  interface.  All  SCSI  commands  are  parsed  through  this 
module,  ReadAVrites  to  the  drive  and  Move  Mediums  to  the  robot.  Additionally,  a  16  MByte  data 
cache  is  included  in  this  module  for  faster  user  data  throughput,  upgraded  from  the  8  MByte  cache 
used  with  the  SCSI  1  design. 

2.4.2  Operator  Interface 

The  operator  may  issue  commands  from  the  Front  Panel,  the  Maintenance  Terminal,  or  from  the 
Host  over  the  SCSI  bus.  Typically  users  carry  out  all  operations  through  the  Host,  with  the  exception 
of  power  cycling  via  a  Front  Panel  pushbutton.  Additionally  the  Front  Panel  has  a  Self  Test  pushbut¬ 
ton  for  a  go-no  go  test.  The  Maintenance  Terminal  provides  a  method  of  direct  communication  with 
the  Jukebox  for  integration  and  testing  activities. 

2.4.3  Power  Input 

The  Jukebox  is  designed  for  120  Volt  AC,  50  or  60  Hz,  single  phase  operation.  The  average  current 
input  to  the  Jukebox  is  approximately  4  A  rnis.  The  peak  current  input  to  the  Jukebox  is  6  A  rms. 
The  airborne  drive  previously  used  400  Hz  120V  aircraft  power  and  required  conversion  to  50  /  60 
Hz  for  the  fans,  vacuum  pump,  and  circuit  breaker. 


2.5  CYCLE  TIME 

M aximum  cycle  time  was  specified  as  1 5  seconds.  To  meet  this  spec  a  dual  disk  picker  was  designed. 
It  can  handle  two  disks  simultaneously.  This  allows  retrieval  of  a  desired  disk  from  the  cache  while 
the  drive  completes  unload  of  the  prior  disk,  saving  time.  Secondly,  the  picker  mechanism  weight 
was  minimized  to  allow  higher  translation  and  rotation  accelerations  with  reasonable  sized  motors. 

2.5.1  Dual  Picker  Mechanism 

To  minimize  weight  the  picker  utilizes  reinforced  aluminum  sheet  metal  construction,  and  carries 
only  the  small  DC  gear  motors  for  disk  insertion  and  extraction.  The  translation  and  rotation  motors 
are  hard  mounted  to  the  frame  and  they  drive  the  picker  through  toothed  belts.  This  ultimately  re¬ 
duces  the  weight  of  the  entire  unit  by  providing  a  lightweight  picker  structure  and  allowing  selection 
of  smaller  motors. 

2.5.2  Rotation  and  Translation  Stepper  Motors 

Stepper  motors  were  selected  to  drive  the  rotation  and  translation  mechanism.  This  choice,  instead 
of  DC  or  other  type  motors,  reduced  design  and  integration  cost.  The  Stepper  motors  selection  per¬ 
mitted  an  off  the  shelf  motor  and  controller  with  simple  custom  software  to  be  used.  Analysis 
showed  open  loop  step  operation  to  give  sufficient  position  accuracy  for  both  translation  and  rotation 
positioning,  avoiding  use  of  feedback  from  absolute  position  encoders.  A  ’’home”  flag  sensor  mark- 


ing  a  reference  position  for  each  motion  axis  was  used.  At  power-up  each  stepper  automatically 
locates  the  reference  position  and  bases  future  motion  on  step  counts  from  this  location.  This  refer¬ 
ence  location  provides  a  simple  means  of  automatic  power-up  mechanism  realignment. 

2.6  JUKEBOX  SYSTEM  CONTROL 

To  control  the  robotics  mechanism  a  single  board  computer  with  both  VME  and  RS232  interfaces 
was  selected.  The  existing  drive  system  controller  handles  drive  operations  while  the  SCSI  2  module 
(see  section  2.4. 1)  handles  user  data  and  control  communication.  Sensors  throughout  the  Jukebox 
monitor  the  assembled  components  and  the  mechanism  and  disk  positions. 

2.6.1  Mechanism  Control  Electronics 

Two  electronic  modules  were  installed  to  control  and  drive  the  mechanisms.  They  are  the  Disk 
Accessing  Mechanism  (DAM)  Conh-oller  module  and  the  DAM  Interface  module.  They  are  located 
in  a  VME  nest  in  the  Support  Rack. 

2.6. 1  ■  1  DAM  Controller  Nest 

A  6  slot  VME  nest  with  an  off  the  shelf  VME  backplane  was  selected  to  house  the  Jukebox  control 
electronics.  This  allows  convenient  use  of  an  off  the  shelf  controller,  inter-module  communication 
using  existing  circuit  designs,  and  future  expansion  of  Jukebox  capabilities.  Four  module  slots  are 
unused,  for  future  installation  of  alternate  drives  or  components  requiring  additional  electronic  mod¬ 
ules. 

For  the  DAM  Controller  a  standard  Radstone  68020  based  single  board  computer  was  purchased. 
This  is  similar  to  the  board  previously  used  as  the  drive  System  Controller.  The  VME  backplane 
is  used  for  communication  with  the  DAM  Interface  for  the  purpose  of  motor,  brake,  and  sensor  con¬ 
trol.  The  Radstone  module’s  triple  RS232  ports  are  used  for  interface  with  the  stepper  motor  index¬ 
ers,  the  disk  drive  electronics  unit,  and  the  diagnostic  terminal  interfaces.  Firmware  written  in  C 
coordinates  all  Jukebox  media  movement  operations. 

A  single  custom  electronics  module,  the  DAM  Interface,  was  designed  for  the  motor,  brake,  and  sen¬ 
sor  drive  circuitry.  Commands  are  received  over  the  VME  bus  from  the  DAM  Controller. 

2.6. 1.2  Rotation  and  Translation  Motors  and  Indexers 

An  indexer  driver  was  purchased  for  each  of  the  two  stepper  motors.  These  units  are  programmed 
with  the  required  motion  profiles  using  a  vendor  supplied  high  level  language.  RS232  communica¬ 
tion  with  the  DAM  Controller  is  used  for  command  and  status  messages. 

2.6.2  Safety 

Several  critical  safety  issues  were  addressed  through  a  combination  of  position  and  component  as¬ 
sembly  sensors  and  DAM  Controller  firmware.  Operator  safety  along  with  robotics  mechanism  and 
disk  safety  is  provided. 

2.6.2. 1  Sensors 

Each  component  requiring  operator  setup  during  deployment  of  the  Jukebox  has  a  sensor  indicating 
proper  installation.  Sensors  determine  whether  the  Support  Rack  and  Robotics  Unit  are  fully  mated, 
and  whether  the  end  caps  are  properly  installed.  The  findings  are  acted  upon  during  power-up  in 
such  a  way  as  to  prevent  wayward  fingers  from  entangling  in  a  moving  mechanism. 
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Additional  sensors  monitor  the  position  of  the  mechanisms  and  the  location  of  the  valuable  disks 
during  any  movement.  Over  travel  sensors  on  the  rotation  and  translation  mechanism  force  protect 
against  robot  damage. 

2. 6. 2.2  Firmware  Abort  Scenarios 

On  initial  power-up  the  DAM  Controller  firmware  checks  all  assembly  sensors  for  proper  and  com¬ 
plete  deployment  assembly.  If  a  discrepancy  is  found,  the  drive  and  robot  remain  unpowered,  and 
a  message  describing  the  error  is  displayed  on  the  diagnostic  terminal. 

Disk  and  mechanism  positions  arc  checked  by  the  fimiware  at  each  step  during  all  mechanism  move¬ 
ment  operations.  Watch  dog  timers  are  operated  during  each  sub-stage  during  all  mechanism  move¬ 
ment  operations.  Any  discrepancy  either  position  or  time  will  cause  the  firmware  to  safely  abort 
the  operation.  At  the  present  level  of  software  development,  in  some  cases  the  fault  may  be  recov¬ 
ered  from  fairly  conveniently  or  automatically.  In  general,  all  motors  are  stopped,  all  breaks  are 
applied,  and  a  message  describing  the  eiTor  is  made  available  on  the  appropriate  diagnostic  ports. 
The  Jukebox  will  refuse  further  commands  until  operator  intervention  recovers  from  the  fault. 

2.6.3  Self  Test 

A  go-no  go  Self  Test  operation  was  designed  to  fully  exercise  the  robotics  mechanism  and  drive. 
This  test  loads  and  exchanges  two  cache  disks,  and  performs  an  erase/write/read  bit  error  test  on  the 
drive.  A  front  panel  pushbutton  initiates  the  sequence,  and  a  front  panel  indicator  reports  pass/fail 
status. 


2.7  CAPACITY 

Data  storage  capacity  was  specified  at  100  GBytes.  The  S/TODS  drive  was  designed  for  12  GByte 
14  inch  double  sided  disks,  developed  in  the  airborne  phase  of  the  program  and  used  for  the  Jukebox. 
A  ten  disk  storage  cache  was  designed,  providing  120  GBytes  maximum,  or  over  100  GBytes  with 
an  average  disk  defect  reduced  capacity  of  90%. 

Capacity  may  be  increased  either  by  manually  exchanging  disk  caches,  or  by  a  design  change  ex¬ 
tending  the  robot  frame  and  enlarging  the  cache.  The  cache  was  designed  for  easy  exchange.  In  a 
few  minutes  an  operator  can  substitute  a  fresh  10  disk  cache  for  the  loaded  cache.  The  cache  slides 
out  of  the  case  for  access,  is  an  easy  one  man  lift,  and  is  equipped  with  alignment  keys  and  position 
sensors.  The  mechanical  design  was  done  looking  toward  the  possibility  of  extending  the  internal 
frame  design  upward  and  adding  additional  cache  trays  including  up  to  100  disk  (1.2  TByte)  capacity 
in  10  stacked  caches.  A  new  external  case  design  would  be  required. 

Disk  defects  had  been  found  to  be  a  problem  in  the  airborne  phase.  Twenty-one  of  the  custom  14” 
disks  were  built.  A  number  of  the  disks  provided  the  full  12  GByte  capacity,  though  others  were 
below  the  desired  90%  capacity.  Further  certification  effort  and  drive  modifications  were  made  with 
the  goal  of  gaining  additional  capacity  on  the  available  disks,  with  limited  success. 
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SECTION  3 


JUKEBOX  DESIGN 


3.1  INTRODUCTION 

This  section  describes  the  design  of  the  S/TODS  Jukebox  and  the  required  modifications  to  the  S/ 
TODS  disk  drive.  System,  mechanical,  electrical,  and  firmware  designs  are  covered. 

An  Operation  and  Maintenance  (O&M)  manual  and  an  Interface  Control  Document  (ICD)  were 
written  for  the  Jukebox.  The  O&M  manual  covers  detailed  information  and  instructions  on  the  setup 
and  operation  of  the  Jukebox  System,  along  with  basic  maintenance  instructions.  The  ICD  covers 
the  detailed  user  information  on  the  control,  data,  and  power  interfaces  and  physical  operating  envi¬ 
ronment. 

3.2  SYSTEM  DESIGN 

The  Jukebox  both  functionally  and  physically  is  broken  down  into  two  units,  the  Robotics  Unit  (RU) 
and  the  Support  Rack  (SR).  The  RU  contains  the  disk  movement  mechanism.  The  SR  contains  the 
disk  drive,  disk  storage  cache,  and  the  Jukebox  control  electronics  nest.  For  shipping  the  RU  and 
SR  are  separated,  and  the  Electronics  Unit  (EU),  Disk  Drive  Unit  (DDU),  and  Cache  are  removed 
from  the  SR  and  placed  into  individual  shipping  containers.  Figure  3.2-1  shows  the  major  compo¬ 
nents  of  the  system  along  with  a  Host,  and  diagnostic  terminals  for  the  drive  and  Jukebox  mechanism 
controllers. 

3.2.1  Robotics  Mechanism 

The  RU  contains  the  mechanical  devices  used  to  move  disks  between  the  Cache  and  the  Disk  Drive. 
The  disk  picker  performs  insertion  and  extraction  operations,  where  disks  are  removed  from  a  source 
(cache  or  drive)  and  loaded  into  a  destination  (cache  or  drive).  The  picker  handles  two  disk  simulta¬ 
neously  for  faster  cycle  time.  The  translation  mechanism  moves  the  picker  vertically  between  the 
Drive  and  Cache.  The  rotation  mechanism  inverts  the  picker  before  an  insertion  operation  when 
access  to  the  second  side  of  a  disk  is  requested.  Stepper  motors  are  used  for  the  Rotation  (RX)  and 
Translation  (TX)  drives,  driven  by  the  RX  and  TX  Indexers.  Both  the  motors  and  indexers  are 
mounted  on  the  floor  of  the  RU,  moving  the  picker  through  toothed  belts.  DC  gear  motors  riding 
with  the  picker  are  used  for  disk  insertion  and  extraction,  driven  by  the  DAM  Interface  module  in 
the  SR. 

3.2.2  Optical  Disk  Drive 

The  S/TODS  ADM  airborne  disk  drive  designed  and  built  in  Phase  1  of  the  program  was  utilized 
in  a  slightly  modified  version  for  operation  in  the  Jukebox.  Design  of  the  drive  itself  is  covered  in 
Volume  1  of  this  report,  modifications  are  covered  in  this  volume.  The  drive  consists  of  the  Electron¬ 
ics  Unit  (EU)  and  the  Disk  Drive  Unit  (DDU),  both  of  which  reside  in  the  Jukebox  Support  Rack. 
Required  modifications  from  the  airborne  configuration  were  kept  to  a  minimum,  mainly  involving 
mounting  changes,  disk  loader  modifications,  conversion  to  SCSI  2,  and  control  software  changes. 

3.2.3  System  Control 

System  operations  are  controlled  by  three  purchased  single  board  computers.  The  Disk  Accessing 
Mechanism  (DAM)  Controller  handles  aU  disk  movement  operations  between  the  Cache  and  the 
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drive.  Jukebox  power  cycle  sequencing,  and  the  Jukebox  diagnostic  terminal.  The  Drive  System 
Controller  handles  read/write  operations,  the  drive  loader  mechanism,  and  the  Drive  diagnostic  ter¬ 
minal.  The  SCSI  2  Adapter  interfaces  to  the  Host  over  SCSI,  parses  read/write  and  move  medium 
input  commands,  and  handles  the  16  MByte  data  cache  operations.  Both  the  System  Controller  and 
the  SCSI  Adapter  are  located  in  the  EU.  The  DAM  Controller  is  located  in  the  DAM  Controller  Nest. 

The  Rotation  (RX)  and  Translation  (TX)  stepper  motors  are  driven  by  the  RX  and  TX  Indexers,  lo¬ 
cated  in  the  RU.  Their  motion  sequences  are  coordinated  by  the  DAM  Controller.  The  Picker  mech¬ 
anism  is  controlled  by  the  DAM  Controller  through  the  DAM  Interface  module.  The  DAM  Interface 
module  also  contains  the  drive  electronics  for  the  small  dc  motors,  brakes,  and  sensors. 

3.2.4  System  Communication 

External  Host  communication  is  via  a  SCSI  2  interface.  Diagnostic  information  and  maintenance 
control  for  the  drive  and  robot  are  exchanged  with  terminals  through  RS232  interfaces.  Internal 
communication  between  the  stepper  indexers,  DAM  Controller,  and  Drive  System  Controller  is  also 
conducted  via  RS232  interface. 

3.2.4. 1  SCSI  2  Host  Interface 

One  SCSI  2  port  is  used  for  all  command,  data,  and  status/error  reporting  to  the  Host.  The  SCSI 
2  Adapter  module  interfaces  the  Host  to  the  robotics  mechanism  and  the  disk  drive. 


Three  methods  of  Jukebox  control  are  available.  A  user  in  a  typical  operational  scenario  does  all 
operational  control  from  the  Host  over  the  SCSI  bus.  The  Jukebox  Eront  Panel  contains  power  and 
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self  test  buttons  and  status  indicator  lamps.  Diagnostic  terminals  for  the  DAM  Controller  and  Disk 
Drive  may  be  used  for  the  exchange  of  control  and  status  information  with  the  Jukebox  and  Drive 
respectively.  These  terminals  provide  direct  access  to  the  individual  components  of  the  system  both 
for  integration  and  maintenance  operations  and  for  fault  diagnosis. 

3.2.4.3  Jukebox  Internal  Communication 

Communication  internally  between  the  various  control  components  of  the  Jukebox  is  done  over 
VME,  VSB,  and  RS232.  The  SCSI  Adapter  communicates  with  the  Drive  System  Controller  via 
the  VME  bus  in  the  EU,  and  transfers  data  to  the  drive  track  buffer  over  the  EU’s  VSB  bus.  The 
DAM  Controller  communicates  with  the  Drive  System  Controller  via  a  dedicated  RS232  connection 
and  with  the  RX  and  TX  Stepper  Indexers  over  another  dedicated  RS232  port.  Messages  between 
the  SCSI  Adapter  and  DAM  Controller  are  sent  through  the  Drive  System  Controller  via  their  VME 
and  RS232  connections. 

Control  of  the  DAM  Interface  module’s  drive  circuitry  by  the  DAM  Controller  is  done  via  a  second 
VME  bus  in  the  Controller  nest.  The  DAM  Interface  drive  outputs  are  hardwired  to  the  various  elec¬ 
tro-mechanical  components  of  the  Jukebox. 

3.2.5  Deployment 

For  shipment  and  rapid  deployment  the  Jukebox  splits  into  easily  manageable  sub-components.  The 
RU  and  SR  cases  separate  and  covers  are  closed  over  all  openings.  The  Robotics  Unit  and  Support 
Rack  cases  become  their  own  shipping  containers.  The  units  may  be  wheeled  about  individually 
in  the  upright  position  or  lain  prone  on  their  feet  and  then  carried  coffin  style  using  the  four  side 
handles.  Prior  to  shipment  the  EU,  DDU,  and  Cache  are  removed  from  the  SR  and  placed  in  individ¬ 
ual  foam  lined  containers.  This  lightens  the  SR  and  reduces  the  potential  for  shock  loading  on  the 
SR  frame  and  component  tray  structure.  Overall,  separate  shipment  makes  it  easier  to  meet  the  trans¬ 
port  shock  and  vibrations  specifications.  Figure  3.2.5-1  shows  the  Jukebox  in  the  shipping  configu¬ 
ration. 

3.3  MECHANICAL  DESIGN 

The  Jukebox  mechanical  design  consists  of  the  external  shipping  Cases,  internal  component  support 
Frames,  and  the  Robotics  Mechanism.  Major  design  considerations  were  the  specifications  for  ease 
and  speed  of  deployment,  disk  access  cycle  time,  and  transport  shock/vibration. 

3.3.1  External  Cases 

The  Robotics  Unit  (RU)  and  Support  Rack  (SR)  external  Cases  contain  and  protect  the  Jukebox  com¬ 
ponents.  The  cases  become  shipping  containers  when  separated  and  closed  by  their  associated  cov¬ 
ers.  Construction  is  heavy  wall  aluminum  with  internal  stiffening  members.  These  vendor  supplied 
cases  are  designed  to  tolerate  rough  handling.  When  the  Jukebox  is  assembled  and  operating  the 
Cases  seal  the  interior  from  atmospheric  dust  and  dirt,  and  provide  EMI  protection.  Figure  3.3. 1-1 
shows  the  two  cases  in  the  mated  configuration. 

Each  case  has  4  handles,  2  along  each  side,  for  hand  carrying  the  separated  units  in  a  prone  position. 
When  upright,  casters  allow  rolling  the  units  while  either  separated  or  mated. 

The  SR  has  openings  for  the  Front  Panel,  Service  Panel,  and  an  EU  cooling  air  exhaust  duct.  The 
RU  has  an  opening  for  the  EU  cooling  air  inlet  duct.  Doors  with  integral  gaskets  are  provided  to 
cover  these  openings  during  shipment. 
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Two  removable  Endcaps  cover  the  sides  of  each  case  for  shipment.  The  inside  Endcap  on  each  is 
removed  and  stowed  when  the  cases  are  mated  for  deployment.  The  outside  Endcaps  may  be  re¬ 
moved  for  access  to  the  Jukebox  components.  For  demonstration  purposes,  an  Endcap  with  an  ob¬ 
servation  window  was  built  for  the  RU,  allowing  viewing  of  the  mechanism. 

3.3.2  Internal  Frames 

All  Jukebox  internal  components  are  mounted  on  two  frames,  one  for  the  RU  and  one  for  the  SR. 
The  frames  are  welded  aluminum  tube  box  frame  structures,  mounted  in  the  shipping  Cases  on  wire 
rope  vibration  isolators.  When  the  RU  and  SR  are  mated  for  deployment,  tapered  guide  pins  and 
spring  loaded  hand  latches  along  the  mating  ends  of  the  frames  precisely  align  and  combine  the 
frames  into  one  rigid  structure. 

3.3.3  Robotics  Unit  Internal  Components 

The  RU  contains  the  disk  movement  robotics.  The  robotics  consist  of  the  Picker  Assembly,  the 
Translation  Mechanism,  and  the  Rotation  Mechanism.  The  Picker  is  translated  to  a  desired  disk 
location,  and  rotated  for  access  to  the  second  side  of  a  disk. 

■3.3.3. 1  Disk  Picker  Assembly 

Insertion  and  Extraction  operations  from  the  Drive  and  Cache  are  carried  out  by  the  Picker  Assem¬ 
bly.  This  unit  rides  up  and  down  on  twin  shafts,  moving  between  the  Cache  and  Drive.  Two  levels. 
Picker  A  and  Picker  B,  enable  the  assembly  to  handle  two  disks  simultaneously.  Figure  3.3.3. 1-1 
shows  the  Picker  Assembly  top  view.  Figure  3. 3. 3. 2-1  shows  a  side  view. 

The  Insertion  Gear  Motors  and  Pinch  Roller  Motors  are  carried  with  the  Picker.  These  DC  gear  mo¬ 
tors  withdraw  the  disk  into  the  picker  and  hold  it  for  translation  and  rotation.  Four  sensors  on  each 
Picker  level  feedback  disk  position  information.  At  the  destination  the  motors  move  the  disk  back 
out  of  the  picker. 

The  Insertion  Gears  are  mounted  on  the  outer  picker,  with  an  upper  and  lower  set.  Insertion  Gears 
provide  the  first  portion  of  the  motion  on  an  extract,  the  last  portion  on  an  insert.  The  Pinch  Rollers 
are  mounted  on  the  inner  picker,  with  a  side  A  and  side  B  set.  They  move  the  disk  to  the  center  of 
the  picker  and  hold  it  in  place  for  translations  and  rotations.  The  four  picker  motors  have  integral 
brakes,  active  with  power  off. 

Disk  rotation  is  accomplished  by  a  180  degree  rotation  of  the  inner  portion  of  the  Picker  Assembly 
about  a  central  horizontal  shaft.  During  a  rotation  the  outer  picker  remains  fixed.  After  a  rotation 
the  inner  and  outer  Picker  are  locked  together  by  a  tapered  pin. 

3. 3. 3. 2  Translation  Mechanism 

Vertical  translation  of  the  Picker  Assembly  between  the  Cache  and  Drive  is  driven  by  a  stepper  mo¬ 
tor.  The  TX  Stepper  Motor  is  mounted  to  the  floor  of  the  RU  frame,  along  with  it’s  Indexer  control¬ 
ler.  Two  gear  driven  toothed  timing  belts  lift  the  picker  to  the  desired  location  along  the  twin  support 
shafts.  Figure  3.3.3.2-1  is  a  side  view  of  the  Robotics  Mechanism,  showing  the  translation  mecha¬ 
nism  with  the  picker  assembly. 

At  each  power  off,  in  preparation  for  potential  shipment,  the  translation  mechanism  parks  the  picker 
at  the  top  of  the  travel.  During  packing,  two  shipping  brackets,  one  of  each  shaft,  are  manually 
locked  against  the  mechanism  to  hold  it  in  place  during  shock  and  vibration.  With  the  picker  at  the 
top  of  the  RU,  the  center  of  gravity  coincides  with  the  center  of  the  unit.  This  makes  tilting  the  case 
onto  its  side  for  hand  carrying  easier. 
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INSERTION  GEAR 


3.333  Rotation  Mechanism 

Rotation  of  a  disk  for  side  2  access  is  accomplished  by  inverting  the  inner  portion  Of  the  Picker  As¬ 
sembly  by  a  stepper  motor.  The  RX  stepper  motor  is  mounted  to  the  floor  of  the  RU  frame,  along 
with  it’s  Indexer  controller.  One  of  the  two  picker  support  shafts  rotates,  driven  through  a  belt  by 
the  RX  motor.  A  pulley  in  the  picker,  driven  by  a  ball  slide  riding  in  a  key  way  on  the  shaft,  rotates 
the  inner  picker  about  a  central  horizontal  shaft. 

3.3.4  Support  Rack  Internal  Components 

The  Support  Rack  (SR)  contains  the  Disk  Drive,  Cache,  DAM  Controller  Nest,  and  the  Front  Panel 
and  Service  Panel.  The  Drive  and  Cache  are  mounted  on  sliding  trays  for  removal  for  shipment. 
Refer  to  Figure  1. 5.2-1  to  see  the  location  of  the  major  components  in  the  SR. 
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Fig.  3. 3. 3. 2-1  Robotics  Mechanism,  Side  View 


3.3.4.1  Cache.  EU.  and  DDU  Drawers 

The  three  removable  components  are  mounted  on  sliding  drawers  in  a  stacked  configuration.  To 
remove  the  units,  the  outer  Endcap  is  first  removed.  Each  units  is  then  slid  out,  unlatched,  and  lifted 
off.  Alignment  keyways  and  hand  operated  latches  are  used  throughout;  no  tools  are  required. 

Sensors  on  each  drawer  and  unit  detect  proper  assembly.  This  allows  the  Jukebox  to  prevent  mecha¬ 
nism  power  up  if  the  assembly  process  is  not  completed  correctly. 


3.3.4.2  Disk  Cache 

The  Disk  Cache  holds  ten  disks,  each  in  a  standard  commercial  14”  carrier.  Construction  is  light¬ 
weight  sheet  metal  and  plastic.  The  Cache  includes  a  fail  safe  disk  latching  mechanism  and  top 
mounted  handles.  A  keyway  precisely  aligns  the  unit  onto  the  SR  tray,  allowing  easy  installation 
and  removal.  The  Cache  can  rapidly  be  swapped  with  another  10  Disk  Cache  if  an  operational  sce¬ 
nario  uses  very  large  amounts  of  data.  An  internal  sensor  monitors  disk  position  and  verifies  that 
all  10  disks  are  properly  inserted  and  latched.  A  second  sensor  monitors  the  position  of  the  Cache 
on  the  pull-out  tray,  verifying  proper  installation  and  fastening  of  the  unit.  One  electrical  connector 
brings  out  the  signals  for  the  sensors  and  the  latch  release  solenoid  drive.  Figure  3.3.4.2-1  shows 
the  cache  with  10  disks  loaded. 


Handle 
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Solenoid 


Electrical 

connector 


Figure  3. 3. 4. 2-1  Disk  Cache,  side  view 


3. 3.4.3  DAM  Controller  Nest  and  Power  Supply 

An  off  the  shelf  6U  VME  card  cage  mounted  above  the  cache  holds  the  DAM  Controller  and  DAM 
Interface  electronics  modules.  The  nest  backplane  is  standard  VME.  The  modules  remove  through 
the  outside  Endcap  and  may  be  installed  on  extender  boards  for  service. 

Although  only  two  modules  were  used  in  the  Jukebox  design,  a  6  card  nest  was  installed  for  future 
expansion  of  capabilities. 

The  power  supply  for  these  modules  is  mounted  to  the  top  of  the  SR  frame.  The  power  supply  is 
heat  sunk  to  the  frame.  The  supply  was  purchased  as  a  semi-custom  ruggedized  unit  with  all  re¬ 
quired  DAM  Controller  Nest  power  outputs  in  one  package,  and  with  logic  control  on/off  capability. 

3. 3.4.4  Cooling 

Heat  is  removed  from  the  Jukebox  by  a  combination  of  convection,  conduction  and  radiation.  The 
Drive  EU  is  the  major  source  of  heat.  The  drive  EU  is  cooled  by  convection  using  external  ambient 
air  forced  through  cooling  ducts.  The  remainder  of  the  heat  is  removed  by  convection  within  the 
case,  conduction  through  the  aluminium  case  skin,  and  by  convection  and  radiation  from  the  cases 
external  surfaces. 

The  Drive  EU  contains  the  majority  of  the  electronic  modules  and  component  in  the  Jukebox  system. 
An  inlet  duct  in  the  rear  wall  of  the  RU  brings  in  outside  air.  Fans  in  the  EU  draw  the  air  through 
the  electronics  modules.  An  exhaust  duct  carries  this  air  out  through  a  vent  in  the  SR  end  cap.  The 
vents  contain  filters  for  EMI  and  air  particulate  protection.  This  airflow  path  is  sealed  off  from  the 
rest  of  the  Jukebox,  to  prevent  particle  infiltration  of  the  mechanism  and  drive. 
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Fans  in  the  RU  and  SR  circulate  the  isolated  internal  air  in  a  controlled  manner  through  the  heat  gen¬ 
erating  components  and  along  the  inside  walls  of  the  cases.  Heat  is  radiated  away  by  the  dark  cases. 
Internal  temperature  rise  is  approximately  10  degrees  C  above  ambient.  The  internal  air  is  gasket 
sealed  from  the  outside  air,  protecting  the  disks,  drive,  and  mechanism  from  contamination.  Opera¬ 
tion  in  environments  with  large  amounts  of  airborne  dust  and  dirt  will  not  harm  the  Jukebox. 

3.3.5  Deployment 

The  Jukebox  is  designed  to  require  less  than  30  minutes  for  2  men  to  setup  or  teardown  without  tools 
for  shipment .  The  EU,  DDU,  and  Cache  mount  using  precise  key  way  alignments  onto  their  trays. 
The  internal  frames  latch  together  with  tapered  alignment  pins  automatically  centering  the  compo¬ 
nents  as  the  frames  are  mated.  Hand  operated  latches  are  used  on  the  external  case  joint,  endcaps, 
internal  frames,  and  component  trays.  Casters  on  the  bottom  of  the  cases  allow  the  units  to  be  rolled 
around  individually  during  setup,  and  after  being  mated. 

3.3.5. 1  System  Setup  and  Teardown 

To  assemble  the  Jukebox  after  shipment  RU  and  SR  cases  are  stood  upright  and  mated,  and  the  EU, 
DDU  and  Cache  are  installed.  Figure  3.3.5. 1—1  shows  the  deployment  assembly  procedure. 

3. 3.5. 2  Ruggedness 

The  design  incorporates  heavy  duty  frames  and  cases  with  internal  isolators  for  the  15  inch  drop  and 
vibration  requirements  in  the  shipping  configuration.  Wire  rope  isolators  reduce  transmitted  force 
to  40G’s  on  the  internal  frames.  Three  to  four  inches  of  sway  space  (dependent  on  the  axis)  is  allotted 
for  the  frames  to  move  on  their  isolators  internal  to  the  cases.  All  components  are  designed  to  survive 
the  transmitted  shock. 

Gasket  sealing  on  all  openings  in  the  shipping  configuration  prevents  condensation  from  affecting 
the  units  during  transit  and  storage.  All  components  are  designed  to  meet  or  exceed  the  op  and  non- 
op  temperature  range. 

3.4  ELECTRICAL  DESIGN 

The  Jukebox  elecuical  design  consists  of  the  DAM  Controller  nest,  modules,  and  power  supply; 
Jukebox  motors,  brakes,  and  sensors;  cabling;  Front  and  Service  Panels;  and  Drive  EU  and  DDU 
modifications. 

3.4.1  DAM  Controller  Nest 

This  6U  commercial  standard  VME  Eurocard  nest  houses  the  DAM  Controller  and  DAM  Interface 
electronic  modules.  The  backplane  is  standard  VME  on  connector  1,  no  connections  on  connector 
2.  The  modules  communicate  over  VME.  Connector  2  is  used  for  custom  Jukebox  I/O  signals.  Four 
spare  slots  are  available  for  future  functionality  upgrades. 

3 .4. 1 . 1  D  AM  Controller  Module 

A  Radstone  68-23  ruggedized  single  board  computer  was  selected  to  control  the  Jukebox.  This  6U 
VME  Eurocard  module  is  based  on  a  20  MHz  68020  microprocessor,  with  VME  and  RS232  capabil¬ 
ities. 

3.4.1.2  DAM  Interface  Module 

A  second  6U  VME  module  was  designed  to  drive  the  motors,  brakes,  and  sensors  of  the  Jukebox. 
This  mixed  signal  analog/digital  10  layer  printed  circuit  board  receives  all  control  signals  from  the 
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Fig.  3.3.5. 1-1  S/TODS  Jukebox  Assembly  Procedure 


DAM  Controller.  The  digital  circuitry  is  implemented  in  two  Xilinx  3090  field  programmable  gate 
arrays  (FPGAs).  Figure  3.4. 1.2-1  shows  the  DAM  Interface  basic  block  diagram. 

3.4. 1.3  DAM  Controller  Power  Supply 

An  Arnold  Magnetics  semi-custom  power  supply  was  purchased  to  provide  all  DC  power  used  for 
the  DAM  Controller  nest,  and  the  electro-mechanical  components  driven  by  the  DAM  Interface 
module.  A  logic  power  up/down  control  enables  the  DAM  Interface  to  take  over  control  once  the 
Jukebox  is  powered  up,  allowing  software  control  of  the  power  down  sequence.  The  following  volt¬ 
ages  are  provided  +/-  5V,  +/-12V,  and  +28 V. 

3.4.2  Sensors 

All  Jukebox  sensors  are  driven  by  the  DAM  Interface  module.  Infrared  optical  and  mechanical  sen¬ 
sors  are  used  where  appropriate.  Circuitry  on  the  DAM  Interface  filters  noise  and  determines  make/ 
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Figure  3.4. 1.2-1  DAM  Interface  Block  Diagram 


break  levels  on  each  sensor  signal,  and  reports  the  value  when  requested  or  generates  an  interrupt 
to  the  DAM  Controller  software  via  VME. 

3.4.2. 1  Jukebox  Sensors 

Jukebox  sensors  monitor  the  position  of  the  Translation  Mechanism,  and  verify  proper  and  complete 
assembly.  The  Picker  Assembly  has  a  end  mounted  flag,  which  breaks  the  beam  of  four  optical  sen¬ 
sors  marking  four  physical  reference  locations.  Each  component  assembled  in  deployment  setup 
of  the  Jukebox  has  a  sensor  verifying  installation  and  proper  alignment.  The  sensors  are  either  opti¬ 
cal  or  mechanical  as  appropriate.  Figure  3.4.2. 1-1  shows  the  location  of  the  Jukebox  Sensors. 

3.4.2. 2  Picker  Assembly  Sensors 

The  Picker  Assembly  carries  optical  sensors  detecting  disk  position  and  rotation  position.  On  each 
inner  picker  level  (A  level  and  B  level)  four  sensors  continually  monitor  disk  position  for  speed  con¬ 
trol  during  insertion  and  extraction.  Before  disk  translation  or  rotation  is  initiated  proper  disk  center¬ 
ing  within  the  inner  picker  is  confirmed.  Four  additional  optical  sensors  mark  4  reference  positions 
of  the  inner  picker  rotation  mechanism.  Figure  3.4.2. 2-1  shows  the  Picker  Sensors. 

3.4.3  Service  Panel  Electrical  Design 

The  Service  Panel  contains  the  AC  power  input  wiring  and  control  circuitry.  The  toggle  style  input 
circuit  breaker  is  normally  left  on  when  the  Jukebox  is  deployed.  System  power  is  controlled  by 
an  illuminated  pushbutton  on  the  Front  Panel.  A  second,  pop  out  style  circuit  breaker  is  used  to  pro¬ 
tect  the  drive.  The  Service  Panel  contains  4  AC  solid  state  relays  controlling  power  to  the  RU,  the 
cooling  fans,  and  the  Drive.  These  relays  are  controlled  by  the  DAM  Controller  through  drive  cir¬ 
cuitry  on  the  DAM  Interface.  EMI  filtering  is  provided  on  the  AC  input  lines.  Figure  3.4.3-1  shows 
the  Service  Panel. 
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Fig.  3.4.2. 1-1  Jukebox  Sensors 


The  Service  Panel  also  contains  two  SCSI-2  connectors  (”mini-50”  type)  for  daisy  chaining  onto 
a  SCSI-2  bus.  Input  and  output  are  interchangeable.  An  external  active  terminator  is  used  when 
at  the  end  of  the  bus. 

3.4.4  Front  Panel  Electrical  Design 

The  Front  Panel  contains  push  buttons  and  status  indicators  for  Power,  Self  Test,  and  Auto/Manual, 
and  it  includes  two  RS-232  diagnostic  ports  for  the  DAM  Controller  and  the  Drive  System  Control¬ 
ler.  The  buttons  and  status  indicators  are  driven  by  the  DAM  Interface  module.  Figure  3.4.4-1 
shows  the  Front  Panel. 

At  power  up  the  power  push  button  turns  on  the  DAM  Controller  Nest  only;  all  other  power  is  soft¬ 
ware  controlled  via  the  solid  state  relays  in  the  Service  Panel.  The  switch  is  illuminated  when  power 
is  on.  After  normal  power  up  a  second  push  of  the  power  push  button  generates  an  interrupt  request¬ 
ing  a  power  down.  If  there  is  no  operation  in  progress  and  no  mechanism  faults  then  a  software  con¬ 
trolled  power  down  sequence  is  initiated.  The  red  and  green  READYLED&  indicators  show  Jukebox 
system  status. 

The  Self  Test  push  button  generates  a  Self  Test  request  to  the  DAM  Controller,  if  no  operation  is  in 
progress  a  Jukebox  self  test  is  initiated.  The  read  and  green  SELF  TEST  indicators  display  the  results 
of  the  go-no  go  test. 
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Fig.  3.4.2.2-1  Picker  Sensors 


The  AUTO  MANUAL  pushbutton  and  indicators  are  not  used.  Wiring  to  the  DAM  Interface  is  pro¬ 
vided  for  future  use. 

3.4.5  Cabling 

The  cabling  harness  for  the  RU  and  the  SR  was  designed  to  drop  in  with  some  manual  wiring  connec¬ 
tions  required.  An  outside  cable  shop  built  the  harnesses.  Installation  and  limited  final  wiring  was 
done  inhouse.  Two  military  twist  lock  connectors  carry  power  and  signals  across  the  joint  between 
the  RU  and  SR  cases.  Ribbon  cable  is  used  for  connection  to  the  DAM  Controller  Nest,  and  for  the 
Z  fold  cable  carrying  Picker  Assembly  signals  up  and  down  with  the  Picker  translation. 

3.5  SOFTWARE  DESIGN 

There  are  five  software  packages  written  for  the  Jukebox  microprocessors.  These  Computer  Soft¬ 
ware  Configuration  Items  (CSCIs)  are: 

1  DAM  Controller  CSCI 

function:  controls  and  coordinates  Jukebox  mechanisms 

target:  68020  based  Radstone  single  board  computer  in  the  DAM  Controller  nest 

2  Drive  System  Controller  CSCI 

function:  controls  optical  disk  drive 

target:  68020  based  Radstone  single  board  computer  in  the  EU 
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3  SCSI  Adapter  CSCI 

function:  handles  SCSI  2  interface  and  data  cache 

target:  68040  based  Synergy  single  board  computer  in  the  EU 

4  Translation  Indexer  CSCI 

function:  controls  translation  mechanism  stepper  motor  sequences 
target:  68040  based  Compumotor  stepper  indexer 

5  Rotation  Indexer  CSCI 

function:  controls  rotation  mechanism  stepper  motor  sequences 
target:  68040  based  Compumotor  stepper  indexer 
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3.5.1  DAM  Controller  Software 

The  DAM  Controller  software  controls  and  coordinates  all  Jukebox  disk  movement  operations,  han¬ 
dles  mechanism  safety  checks,  and  initialization/power  down  sequencing.  The  code  runs  on  a  68020 
CPU  on  the  DAM  Controller  single  board  computer.  The  majority  of  the  code  is  written  in  C,  with 
some  initialization  and  module  hardware  routines  written  in  assembly  language  when  necessary. 
There  are  approximately  7100  lines  of  code  in  this  package. 

3.5.1. 1  Architecture 

The  code  is  state  driven,  with  an  executive  passing  control  in  turn  to  each  of  13  Computer  Software 
Components  (CSC’s).  Each  CSC  maintains  a  current  state,  performs  an  incremental  function  when 
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called,  and  returns  control  to  the  executive.  Communication  between  CSC’s  is  accomplished  via 
messages,  where  each  CSC  has  a  message  queue.  Interrupts  are  used  for  critical  mechanism  control, 
timer  functions,  and  RS232  port  character  I/O.  The  CSC’s  are;  Executive;  Initialization;  Disk  Drive 
Interface;  Monitor;  Terminal;  Motor  Control;  Jukebox  Operations;  Front  Panel;  Self  Test;  Run  Time 
Library;  Timer;  Interrupt;  and  HSI  Tool. 

3. 5. 1.2  Executive  and  Initialization 

The  Executive  CSC  performs  power-up  initialization  of  the  other  CSCs,  the  CPU  module,  and  the 
DAM  Interface  module,  and  controls  the  execution  of  the  other  CSCs  by  evoking  each  in  turn  in  a 
round  robin  manner.  Initialization  performs  the  safety  checks  and  power  up  sequencing  of  the  Juke¬ 
box,  and  coordinates  the  mechanism  position  setup  sequences  required  prior  to  user  operations. 

3.5. 1.3  Self  Test 

The  Self  Test  CSC  executes  a  sequence  of  Jukebox  operations  which  fully  exercise  the  mechanism 
and  drive  when  the  front  panel  Self  Test  button  is  depressed.  Status  of  the  test  results  are  reported 
via  green  GO  and  red  NO  GO  lamps  on  the  Front  Panel. 

3.5. 1.4  Robotics  Control 

All  mechanism  movement  is  coordinated  by  the  DAM  Controller  software.  The  Jukebox  Operations 
CSC  performs  the  high  level  sequencing  control,  with  Motor  Operations  handling  low  level  motor 
and  brake  functions.  Commands  are  sent  to  and  status  received  from  the  RX  and  TX  Indexers,  the 
Disk  Drive,  and  the  DAM  Interface  module. 

3.5. 1.5  Communication 

The  CSC’s  request  action  of  and  report  status  to  each  other  via  messages.  The  messages  are  entered 
and  retrieved  on  a  message  queue  associated  with  each  CSC.  Each  time  a  CSC  is  run  by  the  Execu¬ 
tive  one  message  is  processed  and  acted  on. 

External  communication  to  the  RX  and  TX  Indexers,  diagnostics  terminal.  Drive,  and  DAM  Inter¬ 
face  module  is  done  by  writing  to  and  reading  from  memory  mapped  locations.  The  VME  bus  is 
used  for  the  DAM  Interface  communication.  An  RS— 232  DUART  and  RS— 232  multifunction  pe¬ 
ripheral  are  used  for  the  others. 

3.5.2  SCSI  2  Adapter  Software 

The  SCSI-2  Computer  Software  Configuration  Item  (CSCI)  implements  the  SCSI  interface.  All 
mandatory  SCSI  commands  for  direct-access  devices  and  medium  changer  devices  are  supported. 
A  number  of  optional  commands  are  provided  for  compatibility  with  standard  UNIX  device  drivers 
and  third  party  software  packages.  The  SCSI-2  CSCI  also  provides  up  to  12  Megabytes  of  data 
cache  for  improved  I/O  throughput. 

The  SCSI-2  Software  was  developed  in  ANSI  C  with  a  minimal  amount  of  assembly  language.  The 
low-level  SCSI  bus  interface  was  coded  in  the  NCR  SCRIPTS  language. 

3.5.2. 1  Software  Architecture 

The  SCSI-2  software  is  organized  into  eight  Computer  Software  Components  (CSCs),  each  of 
which  performs  a  separate  function.  A  context  diagram  of  the  SCSI-2  CSCI  is  shown  in  Figure 
3.5.2.1-1. 
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3..5.2.2  Executive  CSC 

The  Executive  CSC  is  activated  on  power  up  to  setup  the  VME  &  VSB  interfaces,  the  NCR  53C7 10 
SCSI  controller  and  initialize  all  global  variables.  The  Executive  CSC  invokes  the  other  CSCs  in 
a  round  robin  fashion. 

3.5.2.3  SCSI  Protocol  CSC 

The  SCSI  Protocol  CSC  is  responsible  for  parsing  commands  and  building  message  structures  which 
are  defined  in  the  SCSI-2  specification.  The  SCSI  Protocol  CSC  forwards  all  data  requests  (i.e. 
SCSI  READ  /  SCSI  WRITE)  to  the  Cache  Manager  CSC.  The  SCSI  Protocol  CSC  also  sends  certain 
SCSI  commands  to  the  System  Controller  Interface  CSC  so  that  they  can  be  forwarded  to  the  System 
Controller  CSCI. 

The  SCSI  Protocol  CSC  separates  the  S/TODS  optical  disk  drive  and  the  Optical  Jukebox  system 
into  two  different  logical  units.  The  optical  disk  is  configured  to  respond  to  accesses  to  logical  unit 
number  (LUN)  0  and  the  medium  changer  will  respond  to  LUN  1.  Table  3.5.2.3-1  lists  all  the 
commands  which  are  supported  by  the  SCSI-2  CSCI. 


SCSI  Command 

S/TODS  Drive 
(LUN  0) 

Jukebox 
(LUN  1) 

FORMAT  UNIT 

✓ 

INQUIRY 

✓ 

✓ 

MODE  SENSE(6) 

✓ 

✓ 

MOVE  MEDIUM 

✓ 

PREVENT  ALLOW  MEDIUM  REMOVAL 

✓ 

✓ 

READ(6) 

✓ 

READ(IO) 

✓ 

READ(12) 

✓ 
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READ  CAPACITY 

✓ 

READ  ELEMENT  STATUS 

✓ 

RELEASE 

✓ 

✓ 

REQUEST  SENSE 

✓ 

✓ 

RESERVE 

✓ 

✓ 

SEND  DIAGNOSTIC 

✓ 

✓ 

TEST  UNIT  READY 

✓ 

✓ 

WRITE(6) 

✓ 

WRITE(IO) 

✓ 

WRITE(12) 

✓ 

Table  3.5. 2.3-1  Supported  SCSI  Commands 


Some  of  the  SCSI  commands  (  FORMAT  UNIT,  PREVENT  ALLOW  MEDIUM  REMOVAL, 
RELEASE,  RESERVE,  and  SEND  DIAGNOSTIC  )  are  only  minimally  supported  so  that  the 
Jukebox  meets  the  SCSI  spec.  An  example  is  the  FORMAT  UNIT  command.  The  Jukebox  accepts 
the  command  and  responds  with  a  GOOD  status,  but  does  not  actually  perform  any  self-test 
functions.  These  features,  however,  may  be  enhanced  or  implemented  at  a  later  time  if  required. 

3. 5.2.4  Cache  Manager  CSC 

The  Cache  Manager  CSC  handles  all  details  associated  with  the  SCSI  RAM  cache.  The  Cache 
Manager  uses  15  Megabytes  of  the  SCSI-2  CPU  card’s  DRAM  as  a  cache  for  SCSI  READAVRITE 
data. 

The  1 5  Megabytes  of  DRAM  is  divided  into  8  separate  cache  lines  or  cache  slots  Each  slot  is  capable 
of  holding  6  tracks  worth  of  data  in  the  outer  most  band  of  the  S/TODS  disk  (band  5).  In  the  inner 
bands,  the  tracks  contain  less  data  so  some  portion  of  the  cache  slot  will  remain  unused.  Dynamically 
adjusting  the  cache  slot  size  -  while  more  efficient  -  is  much  more  difficult  to  manage  and  was  not 
considered  as  a  design  option. 

Data  is  allocated  to  a  cache  slot  on  both  SCSI  READ  and  SCSI  WRITE  operations.  Cache 
replacement  is  based  upon  the  least-recently-used  algorithm.  Modified  data  which  is  stored  in  the 
cache  is  only  written  back  to  the  optical  disk  when  a  cache  slot  needs  to  be  reused.  All  cache  slots 
that  have  been  modified  are  written  back  to  the  medium  before  the  disk  is  ejected  from  the  S/TODS 
drive. 

When  a  SCSI  READAVRITE  command  is  received  the  SCSI-2  software  searches  through  the  cache 
control  structures  to  determine  if  the  requested  data  is  already  cached  in  RAM.  The  cache  search 
must  be  performed  in  fragments  because  the  data  request  could  span  more  then  a  single  cache  slot. 

If  a  fragment  of  the  requested  data  is  found  in  the  cache,  the  software  notes  the  starting  memory 
address  and  the  transfer  length.  This  information  is  then  forwarded  to  the  SCSI  controller’s  DMA 
engine. 

If  a  fragment  is  not  found,  the  SCSI-2  software  finds  an  appropriate  slot  (an  empty  slot  or  the 
least-recently-used  slot)  to  cache  the  data  and  instructs  the  System  Controller  CSCI  to  move  the 
desired  fragment  from  the  disk  into  the  S/TODS  Track  Buffer.  The  SCSI-2  software  moves  the 
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desired  fragment  into  the  cache  and  then  reruns  the  search  for  the  current  fragment.  The  subsequent 
search  will  most  certainly  find  the  desired  fragment  within  the  cache. 

The  search  for  the  next  fragment  of  data  continues  until  the  entire  data  request  has  been  found.  This 
procedure  is  commonly  referred  to  as  ”t aulting”  the  data  into  the  cache.  It  greatly  simplifies  the  code 
because  there  are  only  two  unique  cases  to  handle:  (1)  data  is  in  the  cache  (2)  move  data  from  the 
disk  into  the  cache. 

'^.5.2.5  System  Controller  Interface 

The  System  Controller  Interface  CSC  handles  the  transmission  of  messages  between  the  SCSI-2 
CSCI  and  the  Drive  System  Controller  CSCI.  The  System  Controller  CSCI  and  the  SCSI-2  CSCI 
communicate  through  a  shared  memory  buffer  which  resides  on  the  SCSI-2  CPU  card.  The  System 
Controller  accesses  the  shared  memory  by  reading  and  writing  over  the  VME  bus. 

^■S.2.6  NCR  Manager  CSC 

The  NCR  Manager  CSC  handles  all  implementation  details  specific  to  the  NCR  53C710  SCSI  I/O 
processor.  Capabilities  included:  read/write  SCSI  processor’s  registers,  support  NCR  SCSI 
SCRIPTS  Table  Indirect  Mode,  setup  NCR  SCSI  processor’s  built-in  DMA  bus  master  to 
READAVRITE  data  directly  from/to  Synergy  Memory,  support  “scatter/gather”  data  transfers. 

3.5. 2.7  VSB  Manager  CSC 

The  VSB  DMA  Manager  CSC  is  responsible  for  VSB  DMA  operations  between  the  cache  RAM  and 
the  S/TODS  Track  Buffer.  The  VSB  Manager  sets  up,  starts  and  restarts  DMA  WRITES  from  a  cache 
slot  to  the  Track  Buffer.  The  VSB  Manager  sets  up,  starts  and  restarts  DMA  READs  from  the  Track 
Buffer  into  a  cache  slot. 

3.5.3  Disk  Drive  System  Controller  Software  Modifications 

The  software  in  the  System  Controller  was  modified  for  Jukebox  operation,  mainly  in  the  commu¬ 
nication  and  disk  load  areas.  The  majority  of  the  existing  code  written  for  the  airborne  configuration 
was  unchanged.  A  number  of  drive  performance  enhancements  were  also  made.  The  new  and  modi¬ 
fied  code  was  written  in  C,  with  a  few  low  level  routines  in  assembly.  The  software  package  consists 
of  roughly  20,000  lines  of  code. 

3..5.3.1  Communication 

Communication  software  was  added  to  send  and  receive  messages  between  the  System  Controller 
and  the  DAM  Controller.  Previously  the  System  Controller  used  two  RS232  ports  to  support  the 
Maintenance  Terminal  and  HSI  Tool  diagnostic  terminal  interfaces;  these  were  combined  on  one 
port.  The  second  port  was  dedicated  to  communication  with  the  DAM  Controller.  Command,  status, 
and  error  messages  are  sent  in  both  directions  over  this  interface.  Fault  messages  generated  in  a 
Drive  operation  abort  event  are  sent  to  the  DAM  Controller,  for  display  on  the  Jukebox  Maintenance 
terminal.  A  new  CSC  was  added  to  handle  DAM  communication  functions. 

SCSI  communication  software  was  extensively  modified  both  for  the  SCSI  2  conversion  and  to  han¬ 
dle  forwarding  SCSI  Adapter  -  DAM  Controller  messages.  A  number  of  new  SCSI  commands  were 
added  and  the  previously  used  commands  were  modified.  The  error  reporting  to  SCSI  was  rewritten 
and  expanded  to  support  the  variety  of  more  sophisticated  Host  interface  capabilities  associated  with 
various  Host  software  packages. 

3.5.3. 2  Disk  Loader  Control 

The  disk  loader  control  was  extensively  changed  from  the  airborne  version,  manual  cartridge  load 
and  unload  to  handle  mechanized  carrier  insertion  and  extraction  from  the  Jukebox  picker.  A  moni- 
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tor  for  the  new  disk  ajar  sensor  was  added.  This  function  detects  a  valid  DDU  latch  on  a  newly  in¬ 
serted  disk.  Ajar  detection  allows  the  drive  to  refuse  to  move  the  disk  loader  when  a  disk  is  ajar  due 
to  an  incomplete  insertion.  The  goal  is  to  prevent  damage  to  the  disk  and  mechanism.  During  disk 
movement  operations  Drive  Load  and  Unload  operations  are  requested  by  the  DAM  Controller  over 
the  RS232  interface. 

3. 5. 3. 3  Enhancements 

A  number  of  enhancements  were  made  through  minor  redesign  of  the  drive.  They  are  reflected  in 
changes  in  the  software,  improved  performance  and  reliability,  and  solutions  to  problems  identified 
in  the  airborne  phase  and  during  Jukebox  integration.  Some  of  the  changes  are: 

1  reducing  the  crase/write  magnet  fly  height,  allowing  increased  tolerance  for  magnet 
heating  caused  by  long  term  operations 

2  verification  and  re-lock  of  focus  if  lost  during  stage  jumps 

3  automatic  data  cache  flush  on  disk  unload 

4  Improved  write  laser  start  current  algorithm  when  jumping  to  new  disk  radius 

5  Improved  track  search  algorithm  for  faster  average  track  seek  time,  and  allowing  use 
of  a  number  of  disks  exhibiting  marginal  track  search  performance 

3.5.4  Stepper  Motor  Software 

The  Rotation  (RX)  and  Translation  (TX)  stepper  motors  are  controlled  by  locally  stored  software 
in  the  purchased  Compumotor  RX  and  TX  Stepper  Indexers.  These  two  software  CSCIs  define  and 
control  the  sequence  of  motor  operations  required  for  a  particular  mechanism  movement,  and  define 
motion  parameters  such  as  acceleration  and  velocity.  The  code  is  written  in  an  interpreted  high  level 
Compumotor  language,  and  stored  in  non-volatile  RAM  in  each  indexer.  Execution  of  the  pro¬ 
grammed  sequences  are  requested  by  the  DAM  Controller  via  the  RS232  interface  during  mecha¬ 
nism  operations.  Positional  information,  status,  sequence  completion,  and  fault  messages  are  re¬ 
turned  to  the  DAM  Controller  over  the  same  interface.  Each  CSCI  contains  approximately  200  lines 
of  code. 

3.5.4. 1  Rotation  Indexer  Software 

The  sequence  software  routines  used  to  control  the  RX  stepper  motor  are  Power  Up;  Rotate  to  Park; 
Rotate  Unpark;  Find  Home;  Rotate  to  Normal  Position;  Rotate  to  Inverted  Position;  and  Fault. 

3. 5.4.2  Translation  Indexer  Software 

The  sequence  software  modules  written  to  control  the  TX  stepper  motor  are:  Power  Up;  Find  Home; 
Translate  to  Cache  Position;  Index  Picker  1  to  Picker  2;  Translate  to  Drive;  Translate  to  Park;  and 
Fault. 

3.6  S/TODS  DISK  DRIVE  MODIFICATIONS 

Some  design  modifications  were  required  to  convert  the  drive  from  the  airborne  configuration  to 
the  Jukebox  configuration.  The  modifications  were  made  in  a  manner  that  does  not  preclude  the 
conversion  of  the  drive  back  to  the  airborne  configuration. 

The  Drive  may  still  be  run  independent  of  the  Jukebox,  when  installed  in  the  SR  or  when  setup  on 
a  lab  bench.  To  obtain  local  control  of  AC  input  power,  a  2  pin  molex  connector  on  the  DDU  is 
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swapped  from  its  Jukebox  remote  control  position  to  a  local  control  panel  position.  This  activates 
the  original  airborne  power  switch  on  the  DDU  Front  Panel.  Disks  are  inserted  by  hand  into  the 
loader^and  a  LOAD  pushbutton  is  then  depressed  to  load  the  disk.  Pushing  the  LOAD  button  with 
a  disk  loaded  initiates  an  unload  operation,  and  releases  the  latch  solenoid  for  1  minute  for  a  hand 
disk  extraction.  The  airborne  configuration  EJECT  button  was  modified  for  these  functions.  The 
drive  SELF  TEST  button  retains  its  original  function,  as  do  the  status  LEDs. 

3.6.1  Disk  Drive  Mechanical  Modifications 

The  S/TODS  EU  and  DDU  mounting  configuration  was  changed  from  the  rack  mount  airborne  setup 
to  tray  mount  for  the  Jukebox  SR.  Additional  mechanical  modifications  for  loader  operation  with 
the  Picker  were  required. 

3.6. 1.1  EU  Mechanical  Modifications 

Minimal  modifications  were  needed  to  mount  the  EU.  Four  alignment  guides  were  attached  to  the 
EU  bottom  for  the  Jukebox  tray.  A  sealing  plate  was  added  to  the  EU  rear  fans,  for  mating  with  the 
cooling  air  exhaust  duct.  A  unit— installed  switch  was  added  to  the  underside. 

3.6. 1.2  DDU  Mechanical  Modifications 

DDU  modifications  were  more  extensive,  due  to  the  Jukebox  requirement  of  handing  off  disks  be¬ 
tween  the  Picker  and  the  DDU  disk  loader.  The  DDU  airborne  chassis  was  removed,  replaced  with 
a  partially  covered  transport  pan.  The  front  of  the  pan  is  open,  allowing  the  Insertion  Gears  of  the 
Jukebox  Picker  to  translate  to  the  disk  position  and  withdraw  it  from  the  DDU.  The  DDU  loader 
sheet  metal  and  front  support  shafts  were  modified,  and  new  delrin  guides  added.  Sensors  were  add¬ 
ed  for  detection  of  disk  ajar  and  disk  in  drive  conditions. 

The  DDU  front  control  panel  was  moved  and  mounted  on  the  rear  wall  of  the  transport  pan,  facing 
the  SR  Endcap.  This  new  location  allows  for  integration/service  access  to  the  controls  and  status 
indicators.  The  cooling  fan  was  also  relocated  to  the  rear  of  the  drive. 

3.6.2  Disk  Drive  Electrical  Modifications 

Minor  electrical  modifications  were  required  to  convert  the  S/TODS  Drive  from  airborne  to  Jukebox 
operation. 

3.6.2. 1  EU  Electrical  Modifications 

The  minor  EU  electrical  modifications  involved  new  I/O  connections,  and  conversion  from  400  to 
60  Hz .  A  new  connector  was  added  to  the  rear  for  the  unit-installed  sensor  and  the  RS232  commu¬ 
nications  wiring  to  the  Jukebox.  The  AC  input  circuit  breaker  was  changed  from  a  400  Hz  to  a  60 
Hz  device.  The  backplane  was  slightly  modified  to  accommodate  the  new  SCSI-2  Adapter  module. 
60  Hz  fans  replaced  the  400  Hz  units.  The  single  SCSI-1  I/O  connector  was  changed  to  two  SCSI-2 
connectors  in  order  to  permit  daisy  chaining. 

3.6.2.2  SCSI  2  Adapter 

The  Radstone  SCSI-1  Adapter  and  Radstone  RAM  cards  were  removed  and  replaced.  A  new 
SV-400  SCSI-2  Adapter  module  was  selected  and  purchased  from  Synergy  Microsystems.  It  is 
installed  in  the  EU  VME  nest.  The  SV400  contains  a  Motorola  68040  processor,  an  NCR  53C710 
SCSI  controller,  16  Megabytes  DRAM,  a  VME  bus  interface  and  a  VSB  bus  interface. 

3.6.2.3  DDU  Electrical  Modifications 

DDU  electrical  modifications  involved  the  relocation  of  the  control  panel,  new  signal  cabling,  and 
60  Hz  conversion.  The  cooling  fan  was  changed  from  400  Hz  to  60  Hz.  The  vacuum  pump  400 
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Hz  converter  used  in  airborne  operation  was  removed,  and  the  60  Hz  pump  control  rewired  to  the 
AC  input.  Cabling  for  the  new  sensors  and  unit-installed  switch  was  added  to  a  new  connector  on 
the  transport  pan. 
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SECTION  4 


PERFORMANCE  AND  TEST 


4.1  INTRODUCTION 

This  section  covers  the  results  of  Jukebox  performance  evaluations  made  during  system  integration 
and  test.  Jukebox  mechanism,  Disk  Drive,  SCSI  Interface,  and  Media  performance  results  are  in¬ 
cluded. 


4.2  JUKEBOX  MECHANISM  PERFORMANCE 

The  major  performance  criteria  of  the  mechanism  is  cycle  time,  the  time  required  to  load  a  new  disk 
in  the  Drive.  Other  performance  criteria  evaluated  are  deployment  time,  positioning  accuracy,  and 
mechanism  error  handling. 

4.2.1  Cycle  Time 

Cycle  time  is  defined  as  the  time  to  unload  a  disk  in  the  Drive,  retrieve  a  new  disk  from  the  Cache, 
and  load  the  new  disk  in  the  Drive.  The  Drive  unload  operation  and  Picker  disk  retrieval  occur  simul¬ 
taneously.  Loading  the  disk  includes  the  time  for  the  Drive  to  spin  up,  lock  focus  and  tracking,  read 
the  Defect  List,  and  indicate  READY  for  a  read/write  operation.  The  maximum  cycle  time  occurs 
on  an  exchange,  where  Disk  10  Side  2  is  to  be  retrieved.  Slot  10  of  the  Cache  is  furthest  away,  requir¬ 
ing  the  most  distance  motion  of  the  Picker,  and  Side  2  requires  a  rotation  operation.  The  Cache  slot 
ID  of  the  disk  in  the  Drive  to  be  stored  does  not  affect  cycle  time,  as  the  dual  picker  puts  this  disk 
away  while  the  Drive  is  loading  the  new  disk. 

Specified  maximum  cycle  time  was  15  seconds.  Measured  performance  for  a  worst  case  exchange, 
retrieving  Disk  10  Side  2,  is  15.6  seconds.  This  could  be  improved  to  below  15  seconds  with  further 
perfomiance  tuning.  Loading  a  new  disk  with  no  disk  in  the  drive  varies  from  10.0  seconds  for  Disk 
1  Side  1,  to  14.0  seconds  for  Disk  10  Side  2. 

4.2.2  Deployment 

The  deployment  requirements  were  specified  for  two  man  setup  in  30  minutes.  The  time  require¬ 
ments  were  easily  met;  the  setup  was  found  to  take  15  to  20  minutes  for  two  experienced  people. 
The  sensor  monitoring  of  the  proper  and  complete  assembly  is  very  helpful  in  detecting  and  report¬ 
ing  operator  errors  in  deployment. 

Total  Jukebox  weight  specification  in  the  deployed  configuration  was  600  lbs  maximum.  This  pa¬ 
rameter  was  met  with  the  system  at  585  lbs  assembled. 

The  two  man  lift  specification  was  exceed  on  the  Robotics  Unit  (RU).  Casters  were  added  to  both 
the  RU  and  Support  Rack  (SR),  effectively  allowing  two  people  to  easily  move  the  components 
around  and  assemble  the  Jukebox.  The  remainder  of  the  units  may  be  lifted  by  two  men.  For  trans¬ 
porting  the  RU  and  SR  longer  distances  across  rough  terrain,  where  they  cannot  be  wheeled,  four 
side  handles  are  provided.  Four  people  can  quite  easily  carry  the  individual  units  when  the  units  are 
rotated  over  to  a  prone  position.  Table  4.2.2-1  show  the  transport  weight  and  deployed  weight  of 
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the  Jukebox  components.  Transport  weight  includes  the  additional  endcaps  for  the  RU  and  SR  mat¬ 
ing  ends,  and  the  shipping  containers  for  the  EU,  DDU,  and  Cache.  The  I/O  cables  are  shipped  in 
the  Cache  container,  the  cable’s  weight  in  the  Transport  column  is  included  with  the  Cache  figure. 

Table  4.2.2-1  Jukebox  Transport  and  Deployment  Weight 


MODULE 

TRANSPORT  WEIGHT 

DEPLOYED  WEIGHT 

Disk  Drive  Unit 

150  lbs 

58  lbs 

Electronics  Unit 

170  lbs 

88  lbs 

Robotics  Unit 

253  lbs 

230  lbs 

Support  Rack 

189  lbs 

166  lbs 

Disk  Cache  (w/ 10  disks) 

91  lbs 

32  lbs 

Cables 

included  in  Cache 

nibs 

TOTAL 

853  lbs 

585  lbs 

4.2.3  Mechanism  Positioning  Accuracy 

For  smooth  disk  insert  and  extract  operations  highly  accurate  positioning  is  required  of  the  Picker 
Assembly,  as  referenced  to  the  Drive  and  Cache.  The  absolute  accuracy  and  repeatability  of  both 
the  rotation  and  translation  mechanisms  was  tested. 

Both  rotation  and  translation  mechanisms  do  a  Find  Home  operation  at  power-up,  where  they  veiy 
slowly  and  accurately  seek  a  optically  sensed  reference  position.  All  further  position  movements 
are  based  on  step  counts  from  this  position.  In  addition,  a  second  Registration  sensor  mounted  on 
the  DDU  provides  a  reference  for  each  Translate  to  Drive  operation.  This  allows  the  DDU  to  float 
on  it’s  own  isolators,  and  still  maintain  robotic  positioning  accuracy. 

Machined  alignment  fixtures  placed  in  the  Cache  and  Picker  were  used  to  get  very  precise  alignment 
of  the  Picker,  Cache,  and  DDU  in  the  pitch,  roll,  and  yaw  axis.  To  obtain  smooth  operation  all  three 
axis  must  be  well  aligned.  Repeated  tests  of  translation  and  rotation  were  performed,  with  the  posi¬ 
tions  measured  to  be  well  within  the  1/32  inch  desired  accuracy. 

After  the  final  alignment,  the  Jukebox  has  been  used  in  integration  and  testing  for  nearly  a  year  with¬ 
out  manual  realignment,  including  many  disassembly/re-assembly  and  shipment  to  Florida  by  stan¬ 
dard  commercial  overnight  service.  The  Jukebox  has  also  been  left  powered  for  4  days  without  a 
power-up  automatic  positional  realignment.  The  mechanisms  did  not  develop  any  detectable  posi¬ 
tion  errors  in  this  test. 

4.2.4  Error  Handling 

Appropriate  mechanism  control  system  error  handling  is  important  to  avoid  damage  both  to  the 
mechanism  components  and  to  the  limited  number  of  valuable  S/TODS  disks.  System  integration 
and  performance  testing,  along  with  unusual  event  errors  during  normal  operation,  could  easily 
cause  damage.  The  DAM  Controller  software  continuously  monitors  positions  and  movement  of 
disks  and  the  mechanism  during  aU  operations,  and  will  stop  all  motion  if  an  abnormal  event  occurs. 
Ajar  sensors  in  the  DDU  and  Cache  are  checked  before  every  translation  and  rotation  sub-function 
to  ensure  disks  are  properly  latched  and  not  protruding  into  the  mechanism  ’’free  space”. 

An  Abort  operation  is  performed  by  the  present  DAM  Controller  software  when  a  problem  is  de¬ 
tected.  Aborting  events,  such  as  failure  of  a  disk  to  latch  completely  on  an  insert,  or  a  mechanism 
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reaching  an  overtravel  position  detector,  cause  the  current  mechanism  move  operation  to  stop.  All 
motors  are  shutdown  and  all  brakes  applied  and  a  message  describing  the  event  displayed  on  the 
diagnostics  terminal.  The  Jukebox  will  not  allow  the  initiation  of  further  preprogrammed  mecha¬ 
nism  move  operations  until  the  problem  is  cleared  by  the  operator. 

Various  error  conditions  were  induced  during  different  stages  of  power  up,  load,  and  store  opera¬ 
tions,  such  as  manually  pushing  a  disk  slightly  out  of  position  in  the  Picker  or  Cache,  or  calling  for 
an  insert  with  a  disk  already  loaded  in  the  Drive.  Successful  Aborts  and  no  damage  occurred  in  all 
situations  induced. 


4.3  OPTICAL  DISK  DRIVE  PERFORMANCE 

The  S/TODS  Optical  Disk  Drive,  used  in  both  the  Airborne  and  Jukebox  program  phases,  has  been 
used  for  a  number  of  years  without  major  service  being  required.  This  unit  went  through  environ¬ 
mental  testing  and  flight  testing  in  the  Airborne  configuration.  ReadAVrite  performance  on  the  good 
disk  sides  has  remained  good.  The  Drive  as  installed  in  the  Jukebox  has  been  reliable. 

Minor  repairs  and  adjustments  were  made  to  the  Drive,  such  as  replacing  a  failed  IC  and  re-soldering 
cable  connections.  The  IC  failure  was  likely  caused  by  electrostatic  discharge  damage  to  a  part  type 
that  is  known  by  the  module  supplier  to  be  ESD  sensitive.  The  write  magnet  position  was  changed 
to  reduce  the  magnet  to  disk  fly  height  and  gain  more  write  field  margin. 

A  number  of  performance  improvements  were  made  to  the  Drive  during  the  Jukebox  phase.  The 
goal  was  to  increase  the  system  reliability  and  solve  some  intermittent  problems  not  eliminated  dur¬ 
ing  the  Airborne  phase.  The  changes  were  mainly  in  the  software  control  algorithms  and  are  listed 
in  Section  3.5. 3. 3  Software  Enhancements. 


4.4  MEDIA  PERFORMANCE 

The  custom  disks  developed  in  the  Airborne  phase,  and  used  in  the  Jukebox,  have  exhibited  a  number 
of  problems.  Many  of  the  2 1  disks  built  are  not  fully  useable  by  the  Drive  in  it’s  present  configura¬ 
tion.  A  few  disk  sides  give  excellent  performance  over  the  full  radius.  Therefor  most  read/write 
work  has  concentrated  on  these  disk  sides.  Because  10  disks  with  both  sides  ’’good”  are  not  available 
the  120  GByte  capacity  of  the  Jukebox  is  not  realized  at  present. 

Some  design  and  setup  changes  were  made  to  the  Drive  to  allow  it  to  use  of  disks  with  various  prob¬ 
lems.  The  results  were  good  in  some  areas  and  limited  in  others.  It  is  likely  that  further  work  in 
this  area  would  provide  an  increase  in  total  capacity  with  the  available  disks.  As  more  of  the  prob¬ 
lems  are  addressed,  diminishing  returns  in  additional  capacity  would  be  expected.  It  was  decided 
not  to  spend  additional  time  on  this  effort,  as  the  Drive  operational  configuration  now  used  provides 
enough  capacity  for  the  foreseeable  usage  of  the  Jukebox. 

Media  development  is  reported  in  Appendix  B,  ’’Optical  Disk  Media  for  Tactical  Disk  System”  by 
Dr.  Robert  Hellen  of  3M’s  Rewritable  Optical  Laboratory. 

4.4.1  Disk  Defects 

A  number  of  disk  defect  types  impede  or  prevent  operation  of  the  Drive.  Much  work  at  reducing 
defects  was  successfully  done  during  the  development  of  the  disks  by  the  vendor.  However,  a  num¬ 
ber  of  problem  areas  were  not  completely  solved  in  the  development/limited  production  environ- 
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merit.  The  high  performance  design  of  the  Drive  requires  good  media  for  error  free  operation.  De¬ 
fect  mapping  is  extensively  utilized  to  avoid  undesirable  areas  and  as  expected  the  price  is  reduced 
capacity. 

There  are  several  distinct  types  of  defects.  Some  defects  cause  write  errors  in  small  areas.  Some 
defects  cannot  be  actively  tracked  through.  And  some  defects  cause  write  errors  over  large  areas. 
Various  phenomena  cause  these  defects.  All  defects  are  handled  by  the  Drive  using  a  similar  strate¬ 
gy,  mapping  out  the  affected  areas. 

Three  levels  of  defect  mapping  are  presently  used.  This  provides  the  means  of  avoiding  many  types 
of  disk  defects  while  still  allowing  at  least  partial  use  of  the  majority  of  the  available  disks.  A  bad 
track  map  is  maintained,  where  wholesale  blocks  of  tracks  are  skipped  over.  Secondly,  a  map  of  high 
error  sectors  is  maintained,  where  single  sectors  of  a  particular  track  are  not  written  to.  Both  maps 
are  stored  in  a  system  area  on  each  disk.  Thirdly,  during  disk  writes  a  real-time  verification  detects 
high  error  sub-blocks,  and  they  are  rewritten  to  a  spare  subblock  area. 

4.4.2  Write  Sensitivity 

The  low  write  sensitivity  issue  is  the  largest  performance  problem  reducing  capacity  of  the  final 
disks.  This  problem  shows  up  as  an  increase  in  read  signal  edge  jitter,  reflecting  a  higher  than  nonnal 
read  noise.  A  second  effect  is  a  somewhat  higher  than  normal  required  write  power.  The  Drive  write 
power  servo  handles  the  increased  laser  current,  but  excessive  errors  on  read  prevent  use  of  the  areas 
more  severely  affected.  Changes  were  made  in  the  laser  current  control  software  to  increase  the  erase 
power,  and  improve  the  write  laser  current  start  point  algorithm.  These  changes  allowed  the  drive 
to  operate  over  a  wider  sensitivity  range,  and  enabled  certification  of  the  innermost  bands  of  some 
of  the  low  sensitivity  sides  where  the  problem  is  not  to  severe.  The  write  power  servo  is  working 
harder  than  planned  on  these  areas,  but  appears  to  provide  satisfactory  read  edge  jitter. 

The  effect  is  most  likely  an  MO  layer  issue,  and  is  generally  worse  on  the  outer  radius  of  the  affected 
disks.  Using  a  larger  minimum  feature  size  would  be  required  to  give  more  signal  to  noise  margin, 
allowing  error  free  use  of  these  areas.  This  would  require  a  significant  format  change  in  the  way 
the  Drive  writes  data. 

4.4.3  Track  Search 

The  ability  of  the  Drive  to  locate  a  desired  random  track  varies  significantly  from  disk  to  disk.  On 
the  ’’good”  disks,  tracks  are  generally  located  quickly,  with  only  a  few  head  jumps  required.  On 
others,  a  higher  average  number  of  jumps  are  performed,  with  an  occasional  ’’hangup”  occurring 
for  1  -  2  seconds  before  the  desired  track  is  located.  In  the  hang-up  event  the  head  jumps  back  and 
forth  between  the  same  few  tracks  without  acquiring  the  desired  track.  In  a  few  disks,  hang-ups 
occur  regularly,  and  occasionally  the  tracks  are  never  located  and  the  Drive  gives  up  the  search. 
Jukebox  operation  for  integration  and  test  has  concentrated  on  the  good  disks. 

Some  of  the  bad  search  sides  show  higher  than  normal  eccentricity,  or  an  area  where  the  eccentric 
path  of  the  pilot  track  changes  rapidly.  A  few  exhibit  normal  eccentricity  yet  still  cause  search  prob¬ 
lems,  the  mechanism  in  these  cases  is  unknown.  Once  locked,  the  system  is  capable  of  tracking  the 
higher  eccentricity  disks.  Apparently  the  search  algorithm  had  a  difficult  time  locating  tracks. 

To  allow  use  of  some  of  the  marginal  disks  additional  intelligence  was  added  to  the  track  search  soft¬ 
ware  during  certification  for  10  Jukebox  disks.  The  change  reduces  the  number  of  hang-ups,  and 
also  detects  hang-ups  and  breaks  the  system  out  of  the  event  (limit  cycle  oscillation)  and  retries  the 
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search.  This  allowed  reliable  use  of  a  number,  but  not  all,  disks  that  had  been  previously  set  aside. 
Additional  intelligence  in  the  track  search  software  would  improve  performance  further. 

4,4.4  Certification  and  Capacity 

For  the  Jukebox  the  21  available  S/TODS  disks  were  tested,  and  the  best  10  selected  and  certified. 
The  certification  process  involves  writing  and  reading  the  entire  surface.  The  read/write  perfor¬ 
mance  is  verified  resulting  in  the  creation  of  a  bad  track  map  and  a  bad  sector  map.  Both  maps  are 
written  to  the  disk’s  reserved  system  area.  Due  to  their  various  problems  the  disks  exhibit  varying 
capacity  and  some  of  the  sides  of  the  10  best  disks  are  unusable.  The  approach  adopted  was  to  use 
the  certification  process  as  is,  and  do  only  limited  investigation  of  any  media  related  problems. 

The  total  raw  capacity  of  the  10  best  disks  as  presently  certified  is  62  GBytes.  The  capacity  per  disk 
ranges  from  1  to  12  GBytes.  Four  of  the  10  are  useable  on  one  side  only.  Some  of  the  disk  areas 
certified  exhibit  what  is  considered  marginal  perfomiance.  Operation  with  user  data  over  a  period 
of  time  would  be  needed  to  develop  confidence  in  the  ability  of  the  Drive  to  operate  error  free  over 
these  areas.  There  are  a  few  final  disks  of  the  21  which  have  yet  to  be  tested  completely,  and  a  num¬ 
ber  of  preliminary  disks  which  could  also  be  tested  and  certified. 

4.5  READAVRITE  DATA  RATE 

The  data  rate  between  the  S/TODS  Drive  and  a  SCSI  Flost  can  be  measured  in  a  number  of  ways. 
Depending  on  how  it  is  measured  vastly  different  data  rate  figures  may  result. 

4.5.1  Drive  Design  Data  Rate 

The  Drive  is  designed  for  3.125  MBytes/sec  (25  Mbit)  continuous  data  rate.  On  a  read,  the  drive 
is  capable  of  dumping  an  entire  6  GByte  disk  side  at  3.125  MBy/s  continuously,  buffered  through 
the  track  buffer  and  data  cache.  An  erase  pass  is  required  before  write  in  the  MO  recording  process; 
if  the  disk  is  pre-erased  the  Drive  is  also  capable  of  writing  6  GBytes  at  3. 125  MBy/s  continuously. 
This  is  done  in  the  Certification  process,  where  pseudorandom  data  is  written  to  an  entire  6  GByte 
side  in  32  minutes.  When  moving  data  over  the  SCSI  bus,  the  track  buffer  is  designed  to  handle  data 
flow  from  the  disk  to  the  SCSI  data  cache  without  restricting  the  flow  on  or  off  disk. 

4.5.2  SCSI-2  Data  Cache  Implementation 

The  S/TODS  SCSI  Adapter  module  handles  Host  system  logical  block  addressing  using  a  data 
cache.  The  drive  does  all  disk  read/erase/write  operations  on  a  per  track  basis.  Individual  sectors 
may  not  be  erased  and  written.  The  SCSI  Adapter  reads  disk  data  on  a  multiple  track  basis,  holds 
the  data  in  a  cache,  and  updates  sectors  requiring  change.  Six  track  ’’cache  slots”  are  presently  used, 
as  6  tracks  is  the  capacity  of  Track  Buffer. 

Data  is  transferred  over  the  VSB  bus  in  units  of  one  cache  slot  between  the  Track  Buffer  and  the  data 
cache.  Each  slot  contains  6  tracks  of  data,  of  approximately  1  MByte  (varies  with  disk  Band).  Disk 
operations  are  always  done  in  6  track  units.  On  a  write,  6  tracks  are  transferred  over  V SB  to  the  Track 
Buffer,  then  to  the  disk  sequentially.  Simultaneous  write  mode  handshaking  transfers  from  cache 
to  Track  Buffer  to  disk  are  not  implemented  by  the  present  SCSI  software.  Disk  reads  are  done  with 
simultaneous  handshaking;  as  soon  as  one  full  track  is  read  from  disk  to  the  track  buffer  the  VSB 
transfer  to  the  data  cache  begins. 

Due  to  unique  properties  of  a  given  host  system,  data  is  typically  transferred  over  SCSI  in  much 
smaller  blocks  between  the  Host  and  the  data  cache.  For  example,  the  block  size  is  only  16KBytes 
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for  the  Sun  file  system.  Multiple  blocks  may  or  may  not  be  sent  in  one  SCSI  transfer.  The  idle  time 
and  handshaking  overhead  in  SCSI  is  very  high  when  the  host  system  specifies  single  block  trans¬ 
fers.  Net  overhead  decreases  when  larger  contiguous  block  transfers  are  specified. 

A  write  to  S/TODS  requires  reading  a  cache  slot  (6  tracks)  from  the  disk  to  the  track  buffer,  a  VSB 
transfer  to  the  cache,  then  a  SCSI  transfer  from  the  Host  to  the  cache  updating  a  logical  block.  Fur¬ 
ther  writes  to  logical  blocks  in  the  same  cache  slot  go  directly  to  the  cache  without  disk  reads.  The 
slot  is  left  in  the  cache  until  an  empty  slot  is  required  for  further  operations,  or  the  disk  is  unloaded. 
To  return  the  updated  cache  slot  to  disk  the  6  tracks  are  erased,  then  the  data  is  written  to  the  Track 
Buffer,  then  dumped  to  disk. 

4.5.3  Throughput  Testing 

Bandwidth  and  throughput  are  very  different  figures.  The  bandwidth  of  the  ’’Fast  Nairow”  SCSI 
bus  in  this  context  refers  to  the  10  MByte/sec  transfer  rate  during  the  data  phase.  It  is  a  statement 
of  the  data  clocking  speed.  The  bandwidth  of  the  VSB  bus-Track  Buffer-disk  operations  is  3.125 
MBytes/sec  (reading,  or  writing  to  an  erased  area).  This  gives  the  S/TODS  drive  a  potential  band¬ 
width  of  10  MByte/sec,  3.125  MByte/sec  sustained. 

Throughput  in  this  context  refers  to  the  speed  with  which  the  user’s  data  is  transfeired,  the  speed 
he  sees  when  working  with  the  system  in  a  particular  application.  The  separate  erase  pass,  logical 
block  addressing,  and  sequential  transfer  nature  of  the  Host  -  SCSI  -  Cache  -  Track  Buffer  -  Disk 
operations  of  the  present  implementation  inherently  lower  the  data  throughput  rate.  The  Host  ap¬ 
plication  and  architecture  also  significantly  lower  the  throughput.  The  user  may  observe  a  through¬ 
put  figure  for  large  data  transfers  considerably  less  than  the  observed  data  bandwidth  figure. 

Observation  of  continuous  SCSI  data  write  operations  showed  the  read,  erase,  and  write  disk  access 
operations  occupy  only  25%  of  the  time  used.  Track  searches  use  another  12%,  with  the  rest  used 
by  software  setup.  Sun  disk  drive  and  operating  system,  SCSI  and  VSB  transfers,  and  disk  rotational 
latency. 

Throughput  testing  with  various  Host  applications  was  done.  Three  important  applications  are  tape 
archive  ”tar”  transfers,  file  system  copy  ”cp”  transfers,  and  Metior  HSM  file  system  ”cp”  transfers. 
The  integration  of  these  applications  with  S/TODS  is  discussed  in  Section  5. 

Below  are  some  throughput  benchmarks  measured  with  a  directory  of  ten  3  MByte  map  data  files 
(30  Mbyte  total),  with  the  exception  of  the  Metior  figures  which  were  measured  with  one  30  MByte 
file.  For  reference,  measured  throughput  between  two  internal  Sun  hard  drives  is  included  (both 
rated  at  ”10  MByte/sec”). 
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Table  4.5.3-1  Throughput  Measurements,  Ten  3  MByte  Files 


Data  Transfer  Application 

Write  Throughput 

Read  Throughput 

Sun  File  System  cp 

Sun  hard  drive  -  S/TODS 

220  KBytes/sec 

540  KBytes/sec 

Metior  File  System  cp 

Sun  hard  drive  -  S/TODS 

420  KBytes/sec 

175  KBytes/sec 

UNIX  tar  utility 

Sun  hard  drive  -  S/TODS 

360  KBytes/sec 

490  KBytes/sec 

Sun  file  system  cp 

Sun  hard  drive  -  hard  drive 

1800  KBytes/sec 

1800  KBytes/sec 

The  measured  throughput  to  and  from  S/TODS  varies  considerably  with  modification  of  the  file  sys¬ 
tem  tuning  parameters,  both  for  the  Sun  File  System  and  the  Metior  File  System.  Effort  to  maximize 
throughput  by  tuning  was  done  and  is  discussed  in  Section  5.  The  ”tar”  performance  is  viewed  as 
the  maximum  possible  for  the  present  SCSI-2  implementation.  The  SCSI  bus  bandwidth  is  10 
MBytes/sec,  S/TODS  disk  operations  bandwidth  is  3.125  MBytes/sec  in  all  cases.  It  is  interesting 
to  note  the  tar  read  throughput  is  490/3125  =  16%  of  the  disk  bandwidth;  about  the  same  as  the  Sun 
disk  drive  measured  throughput/bandwidth  of  1.8/10  =  18%.  Write  throughput  is  inherently  slower 
due  to  the  additional  operations  required,  though  it  is  closer  to  the  read  performance  than  was  ex¬ 
pected.  Metior  HSM  read  performance  is  slower  than  was  expected;  perhaps  additional  tuning  ef¬ 
forts  would  improve  this  figure. 


4.6  SCSI  INTERFACE  PERFORMANCE 

Problems  with  the  SCSI  bus  communication  between  the  Sun  host  and  the  S/TODS  Drive  when  run¬ 
ning  at  the  SCSI  Fast  rate  of  10  MByte/sec  occurred  during  system  test,  and  throughout  the  Host 
integration  efforts  discussed  in  Section  5.  The  observed  failures  range  from  a  number  of  missed 
clocks  causing  the  Sun  to  reduce  the  bus  bandwidth  to  1/2  or  1/4  of  the  SCSI  Fast  rate,  to  total  inabil¬ 
ity  to  communicate.  The  bus  problems  were  addressed  by  modify  the  termination  strategy,  careful 
selection  of  cables,  and  the  use  of  differential  signaling  and  a  bus  repeater  in  some  connection  con¬ 
figurations. 


4.6.1  SCSI  Bus  Termination 

One  mechanism  of  SCSI  bus  failure  is  reflections  of  signals  from  the  bus  ends  obliterating  signals 
at  the  detection  point.  At  Fast  SCSI  speeds,  the  round  trip  time  of  a  signal  and  one  reflection  can 
be  50%  of  the  bit  window,  easily  causing  problems.  Many  SCSI  products,  including  the  SCSI  mod¬ 
ule  purchased  for  S/TODS,  use  a  passive  resistor  network  for  termination.  The  passive  network  does 
not  match  the  impedance  of  the  cabling  well,  causing  reflections,  and  allows  crosstalk  between  bits. 


To  reduce  these  effects  the  termination  on  the  Synergy  SCSI-2  module  was  removed  and  an  external 
active  termination  was  installed.  The  active  termination  uses  a  voltage  regulator  and  single  resistor 
termination  to  obtain  low  crosstalk  and  better  impedance  match.  Using  external  termination  also 
allows  S/TODS  to  be  placed  in  the  center  of  a  daisy  chained  bus  rather  than  at  one  end  only. 
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4.6.2  SCSI  Cabling 

It  was  found  that  the  majority  of  SCSI  cables  on  tlie  market  are  not  suitable  for  use  at  SCSI  Fast  rates. 
These  cables  are  sometimes  successfully  employed  (but  not  recommended)  with  very  short  length 
busses  of  a  few  feet  or  less.  A  number  of  different  cables  were  purchased  and  tested,  it  was  found 
that  top  quality  cables  were  required  to  get  to  the  15  foot  bus  length  desired.  The  good  cables  have 
the  correct  impedance  and  pairing,  heavy  shielding,  and  additional  internal  shielding  on  the  critical 
clock  signals. 

With  single  ended  communication,  using  top  quality  cables,  cable  length  between  the  Jukebox  and 
the  Sun  was  limited  to  10  feet  before  bus  problems  occurred.  This  length  requires  the  Sun  to  be  either 
on  top  of  the  Jukebox,  or  on  a  cart  directly  next  to  the  unit.  Total  bus  length  including  Sun,  Jukebox, 
and  Drive  internal  cables  is  about  17  feet,  close  to  the  specified  20  foot  maximum  for  SCSI  Fast 
Synchronous  transfers. 

4.6.3  Single-Ended  vs.  Differential  Communication 

SCSI  busses  may  use  either  single  ended  or  differential  communication.  Some  high  performance 
systems  use  differential  for  it’s  higher  noise  immunity  and  longer  allowed  lengths.  The  vast  majority 
of  SCSI  products  are  single  ended.  This  includes  the  systems  S/TODS  is  likely  to  interface  with. 
For  this  reason  the  Synergy  SCSI-2  module  was  purchased  in  the  single  ended  version. 

The  Sun  used  in  J ukebox  integration  has  both  single  ended  and  differential  SCSI  capability.  A  differ¬ 
ential  to  single  ended  converter  was  purchased  to  allow  use  of  S/TODS  with  the  differential  bus. 
The  differential  SCSI  bus  permits  the  Sun  to  be  located  up  to  75  feet  from  the  Jukebox.  It  also  makes 
integration  and  test  easier  because  it  puts  S/TODS  on  a  separate  bus  from  the  internal  Sun  compo¬ 
nents.  Much  of  the  early  integration  work  was  done  in  this  configuration,  and  few  bus  problems  were 
experienced. 

4.6.4  SCSI  Repeater 

To  connect  to  single  ended  SCSI  equipment  with  cables  longer  than  10  feet  a  SCSI  repeater  was  pur¬ 
chased.  This  device  bidirectionally  repeats  SCSI  signals,  allowing  doubling  of  the  cable  length. 
In  the  lab,  the  Sun  was  located  20  feet  from  the  Jukebox  using  the  repeater  without  causing  bus  er¬ 
rors. 
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SECTION  5 


HOST  INTERFACE  AND  PERFORMANCE  TESTING 


5.1  INTRODUCTION 

This  section  covers  the  integration  between  the  Jukebox  and  various  Host  systems  and  software 
packages.  Host  integration  was  done  over  a  SCSI-2  interface  with  a  Sun  Workstation  and  the  Spe¬ 
cial  Operations  Forces  Planning  and  Rehearsal  (SOFPARS)  system.  Software  packages  integrated 
with  were  the  SunOS  and  Solaris  operating  systems;  Sun  File  Manager;  Air  Force  Mission  Support 
System  (AFMSS);  and  Metior  Hierarchical  Storage  Management  (HSM)  software. 


5.2  CONNECTION  TO  SUN  WORKSTATION 

The  Jukebox  was  connected  to  a  Sun  SPARC  10  workstation  via  the  SCSI  2  bus,  under  both  the  Su¬ 
nOS  and  the  Solaris  operating  systems.  Disk  Drive  read  and  write  operations  with  the  Sun  file  sys¬ 
tem  were  performed.  Jukebox  disk  movement  operations  were  demonstrated  under  control  of  the 
Sun,  via  a  custom  software  disk  load  tool. 

5.2.1  SCSI  2  Connection 

The  Jukebox  was  connected  to  the  Sun  as  a  standard  disk  drive  peripheral,  over  the  SCSI  2  bus.  Fast 
Narrow  options  (8  bits,  10  MBytes/sec).  Both  single  ended  and  differential  connections  were  used 
at  various  times,  though  most  final  integration  effort  used  single  ended.  All  mandatory  commands 
for  a  direct  access  device  and  for  a  medium  changer  device  are  supported,  along  with  some  additional 
commands  found  necessary  for  integration  with  the  Sun  file  system  and  Metior  HSM.  Initial  SCSI 
2  integration  and  performance  testing  are  covered  in  Section  4  of  this  volume. 

5.2.2  Sun  File  System  Operation 

The  Jukebox  was  operated  as  a  normal  Sun  file  system  standard  disk  drive.  A  Sun  ’’Label”  and  ’’For¬ 
mat”  operation  is  done  on  each  disk,  where  directoiy  information  and  file  system  tuning  parameters 
are  written  to  disk.  With  the  disk  loaded  in  the  drive  a  Unix  ’’mount”  operation  is  done.  S/TODS 
then  appears  as  a  standard  directory  to  the  operating  system,  all  Unix  file  manipulation  commands 
work  normally.  The  user  may  copy  files  back  and  forth  to  an  S/TODS  disk,  and  run  application  pro¬ 
grams  using  data  on  S/TODS,  by  simply  changing  to  the  mounted  directory. 

■5.2.2. 1  Tuning  Parameters 

The  values  of  various  tuning  parameters  set  up  in  the  Label  and  Format  operation  are  critical  to  read 
and  write  performance.  These  parameters  were  modified  and  tests  run,  yielding  excellent  perfor¬ 
mance  results  when  optimized  for  S/TODS. 

Initial  file  system  integration,  using  the  Sun  default  tuning  parameters,  gave  poor  results  due  to  the 
differences  in  the  physical  organization  of  data  on  the  optical  disk  as  compared  to  a  magnetic  hard 
drive.  Magnetic  hard  drives  are  inherently  sector  addressable,  and  use  very  small  physical  block 
sizes  as  compared  to  a  large  format  S/TODS  disk.  Standard  file  system  parameters  are  optimized 
for  multihead,  small  block,  sector  addressed  systems.  This  configuration  is  ideal  for  many  small 
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files;  S/TODS  disk  architecture  and  cache  structure  is  optimized  for  transfer  of  large  amounts  of  se¬ 
quentially  located  data.  The  demonstrations  conducted  at  the  end  of  the  Airborne  Phase  used  mainly 
default  parameters,  resulting  in  very  low  throughput  figures.  Subsequent  file  system  investigation 
and  tuning  efforts  resulted  in  an  order  of  magnitude  improvement  in  read  and  write  throughput,  by 
forcing  the  Sun  File  System  to  allocate  logical  blocks  in  a  manner  which  maximizes  the  S/TODS 
Cache  and  physical  data  block  location  utilization. 

Tuning  parameters  which  gave  major  performance  improvements  related  mostly  to  the  logical  block 
allocation  and  disk  information  inodes.  Using  a  large  fragmentation  figure,  a  large  number  of  cylin¬ 
ders  per  group,  and  a  0  rotational  delay  selection  caused  the  file  system  to  allocate  contiguous  logical 
blocks  when  writing  the  large  files  of  the  typical  S/TODS  application.  This  allows  the  system  to 
utilize  the  cache  in  an  efficient  manner,  by  generally  updating  a  large  number  of  file  system  blocks 
before  writing  a  cache  slot  to  disk.  In  this  manner  disk  accesses  are  reduced,  and  each  access  tends 
to  write  or  read  a  larger  volume  of  data. 

A  second  major  improvement  resulted  from  using  a  high  number  of  bytes  per  inode.  The  inodes 
contain  information  about  each  file,  stored  on  disk  in  predetermined  locations  spread  around  the 
disk.  Inodes  must  be  updated  each  time  a  file  is  accessed,  typically  requiring  a  stage  move  as  the 
inodes  are  on  separate  tracks  from  the  data.  With  a  high  bytes/inode  selection  the  number  of  updates 
to  disk  is  reduced,  preventing  the  Drive  from  wasting  too  much  time  jumping  around  updating  in¬ 
odes. 

5. 2. 2. 2  Performance 

The  file  system  tuning  parameters  described  above,  along  a  number  of  others,  resulted  in  good  per¬ 
formance.  Read  and  write  throughput  using  the  copy  ”cp”  command  approached  the  tape  archive 
”tar”  speed,  which  is  seen  as  close  to  the  physical  maximum  throughput  the  SCSI  2  -  S/TODS  inter¬ 
face  will  support.  Further  performance  increases  would  require  modification  of  the  Drive’s  SCSI-2 
interface  implementation,  increasing  both  the  ”tar”  and  ”cp”  measured  throughput. 

5.2.3  Load  Tool 

A  software  tool  was  written  for  the  Sun  to  allow  the  operator  to  move  disks  between  the  Drive  and 
Cache  from  the  workstation.  Both  graphical  (GUI)  and  command  line  versions  were  written  and 
demonstrated.  The  GUI  version  presents  a  window  with  buttons  to  select  disk  number,  side  number, 
and  fetch  or  store  operations.  The  operator  simply  points  and  clicks  on  the  desired  disk  to  request 
a  Jukebox  disk  movement  operation.  The  command  line  version  is  used  where  the  GUI  tool  cannot 
run,  such  as  when  logged  in  remotely  under  rlogin  or  telnet,  or  when  running  AFMSS. 


5.3  AFMSS  MISSION  PLANNER  INTEGRATION 

The  Jukebox  was  integrated  with  the  Air  Force  Mission  Planning  System  (AFMSS).  This  system 
normally  utilizes  multiple  hard  drives  for  storage  of  map  data  used  in  flight  mission  planning.  A 
Sun  hard  drive  was  sent  to  Lockheed  Sanders  and  loaded  with  the  AFMSS  software.  A  Sun  Sparc 
10  at  the  Camden  facility  was  then  booted  from  this  drive,  and  interfaced  via  SCSI  to  the  S/TODS 
Jukebox. 

With  S/TODS  mounted  as  a  standard  UNIX  file  system  the  planning  system  was  integrated.  Maps 
were  loaded  onto  a  number  of  Jukebox  disks  with  tuned  Sun  file  systems  installed.  An  AFMSS  Table 
of  Contents  file  was  generated  for  each  disk  by  the  AFMSS  software,  and  stored  on  each  disk  with 
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the  maps.  This  standalone  mission  planning  system,  consisting  of  a  Sun  workstation,  external  hard- 
drive  with  applications  data,  and  S/TODS  Jukebox  with  map  data  was  then  demonstrated  in  the  lab. 

The  Sun  host  with  the  Jukebox  was  connected  to  the  Lockheed  Martin  network.  This  allowed  opera¬ 
tion  of  the  system  from  anywhere  in  the  company.  Much  of  the  integration  work  was  done  from  the 
office  area  on  a  different  floor,  moving  disks  around  the  Jukebox  remotely.  Lockheed  Sanders  engi¬ 
neers  were  directly  involved  in  the  integration  effort  from  New  Hampshire,  remote  logged  in  to  the 
Sun-S/TODS  system  over  the  common  corporate  network. 

To  operate  AFMSS  with  S/TODS,  the  Load  Tool  is  used  to  request  a  Jukebox  disk  load  and  Sun  file 
system  mount  of  the  disk  with  the  desired  map  data.  The  Load  Tool  is  run  from  a  command  line 
window  within  AFMSS.  S/TODS  is  mounted  to  appear  as  a  standard  hard  drive  to  AFMSS,  and 
map  data  is  accessed  from  the  Jukebox  transparently  to  the  AFMSS  software.  Maps  of  different 
areas  on  different  disks  may  be  loaded  and  viewed  at  will. 

The  read  perfomiance  of  the  Jukebox  under  AFMSS  operation  was  found  to  be  somewhat  slower 
than  hard  drive  map  storage  operation,  as  was  expected.  The  speed  was  found  to  be  reasonably  fast, 
fast  enough  to  be  of  no  concern  to  the  operator.  The  ability  to  have  6  GBytes  of  map  data  under  the 
head,  and  120  GBytes  available  within  15  seconds  from  one  command  line  operation  is  a  significant 
advantage. 

5.4  METIOR  HSM  INTEGEIATION 

The  Metior  Hierarchical  Storage  Manager  (HSM)  software  was  installed  on  the  Sun  host  and  inte¬ 
grated  with  the  Jukebox.  Some  modification  to  the  Jukebox  SCSI  2  interface  software  was  required, 
to  conform  with  Metior ’s  expected  message  formats.  The  installation  became  a  significant  task  due 
to  problems  setting  up  the  Sun  and  the  Solaris  operating  system  to  work  with  Metior. 

Metior  sits  between  the  Sun  file  system  and  the  Jukebox,  managing  the  disks  and  the  robotics  mecha¬ 
nism  transparently  to  the  user.  The  user  accesses  data  on  Jukebox  disks  by  simply  changing  directo¬ 
ries  or  running  applications  with  data  residing  on  the  Jukebox.  Metior  automatically  requests  the 
Jukebox  to  load  and  store  disks  and  access  data.  The  HSM  provides  the  full  Jukebox  capacity  of 
120  GBytes  transparently,  in  a  single  directory  if  desired,  and  potentially  can  read  and  write  data 
faster  than  a  standard  Sun  file  system  is  capable  of. 

A  demonstration  of  Sun/Jukebox  operation  with  the  Metior  file  system  was  conducted.  Files  were 
written  and  read  from  S/TODS  to  the  Sun,  using  the  standard  unix  copy  ”cp”  command.  Metior  was 
shown  to  automatically  request  a  load  of  the  required  disk,  and  return  the  disk  to  the  cache  after 
completion  of  the  operation,  making  the  Jukebox  disk  operations  transparent  to  the  user. 

Measured  write  throughput  with  the  Metior  file  system  was  1 30  KBy te/sec,  and  read  was  200  KByte/ 
sec.  Testing  was  done  on  a  directory  of  sixty  230  KByte  files  (14  MBytes).  This  speed  represents 
an  improvement  of  about  7X  over  the  speed  of  the  system  during  the  Air  Force  demonstrations  at 
the  end  of  the  Airborne  Phase,  where  slow  write  performance  under  the  Sun  File  System  was  an  im¬ 
petus  to  investigation  of  Hierarchical  Storage  Managers.  For  reference,  unix  ”tar”  writes  and  reads 
were  measured  at  400  KBytes/sec  for  the  same  directory.  With  further  performance  tuning,  opera¬ 
tion  under  Metior  should  approach  the  tar  transfer  speed  figure. 

5.4.1  AFMSS  Operation  under  Metior  HSM 

Map  data  was  loaded  onto  S/TODS  disks  through  the  Metior  file  system,  and  AFMSS  operation 
demonstrated.  A  link  to  the  normal  hard  drive  map  directory  was  replaced  with  one  to  a  directory 
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managed  by  Metier,  containing  the  map  data  on  the  Jukebox.  Running  the  AFMSS  package  and 
displaying  map  data  caused  automatic  load  and  read  of  Jukebox  disks,  transparently  to  AFMSS. 
Read  performance,  moving  around  on  an  AFMSS  map  under  Metier,  was  found  to  be  significantly 
slower  than  from  the  tuned  standard  Sun  file  system.  Further  tuning  would  be  needed  to  use  Metier 
with  satisfactory  performance. 


5.5  SOFPARS  INTEGRATION 

The  Jukebox  was  integrated  with  the  Air  Force  SOFPARS  Desktop  mission  planning  system  atHuiT 
burt  Field,  Florida,  running  the  AFMSS  mission  planner.  Disks  were  loaded  and  unloaded  using 
a  Load  Tool  installed  on  the  Sun  workstation,  map  data  was  written  and  read  from  disk,  and  the  plan¬ 
ning  system  operation  with  S/TODS  was  demonstrated.  Overall  performance  was  found  to  be  satis¬ 
factory.  Rapid  setup  and  disassembly  of  the  deployable  Jukebox  system  was  also  demonstrated. 

Connection  to  the  SOFPARS  system  required  simply  installing  the  Load  Tool  on  their  Sun,  adding 
UNIX  link  files  pointing  to  the  Jukebox,  and  attaching  the  Jukebox  to  their  SCSI  bus.  The  Integra^ 
tion  was  done  with  the  Jukebox  mounted  as  a  normal  Sun  file  system,  and  required  no  modifications 
to  the  AFMSS  application  software.  The  Metior  hierarchical  file  manager  was  not  installed  on  the 
SOFPARS  system,  due  to  the  installation/removal  complexity  and  perfonnance  issues. 

SCSI  bus  enors  were  found  to  occur  with  the  intended  cable  setup,  requiring  use  of  veiy  short  cables 
to  gain  reliable  operation.  This  required  placement  of  the  Jukebox  veiy  close  to  the  planning  system, 
acceptable  for  the  demonstration  but  inconvenient  or  impossible  in  other  interface  scenarios.  The 
working  (single  ended)  setup  used  a  six  foot  cable  from  the  S/TODS  EU  to  the  SCSI  repeater,  and 
a  two  foot  cable  from  the  repeater  to  the  planner. 

On  return  to  the  Camden  facility  the  cabling  used  with  SOFPARS  was  setup  with  the  standalone  Sun 
AFMSS  system.  The  observed  problem  was  not  repeated.  Cable  lengths  were  increased  to  the  point 
where  the  SOFPARS  system  would  not  even  boot,  and  still  no  bus  errors  occurred.  It  is  unknown 
if  the  bus  problems  at  Hurlburt  were  related  to  the  SOFPARS  desktop  system  SCSI  bus  itself  or  to 
the  additional  equipment  present  on  the  bus.  Shorter  cables  made  an  obvious  improvement,  pointing 
to  impedance/reflection,  load,  and  crosstalk  problems.  ° 

In  future  demonstrations  or  permanent  installation  of  the  Jukebox  conversion  to  differential  SCSI 
signaling  would  eliminate  cabling  concerns.  A  standalone  converter  would  then  be  used  for  connec¬ 
tion  to  single-ended  Hosts,  located  very  close  to  the  Host  equipment. 
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APPENDIX  A 

LIST  OF  ACRONYMS 


1 

C 

The  C  Programming  Language 

2 

CPU 

Central  Processor  Unit 

3 

CSC 

Computer  Software  Component 

4 

CSCI 

Computer  Software  Configuration  Item 

5 

DAM 

Disk  Accessing  Mechanism 

6 

DDU 

Disk  Drive  Unit 

7 

EU 

(Disk  Drive)  Electronics  Unit 

8 

HSI 

Hardware  Software  Integration 

9 

RU 

Robotics  Unit 

10 

RS-232 

EIA  Standard  for  Computer  Data  Interface,  circa  1965 

11 

SCSI-2 

Small  Computer  Systems  Interface 

12 

STODS 

Strategic  Tactical  Optical  Disk  System 
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MISSION 

OF 

ROME  LABORATORY 


Mission.  The  mission  of  Rome  Laboratory  is  to  advance  the  science  and 
technologies  of  command,  control,  communications  and  intelligence  and  to 
transition  them  into  systems  to  meet  customer  needs.  To  achieve  this, 
Rome  Lab: 

a.  Conducts  vigorous  research,  development  and  test  programs  in  all 
applicable  technologies; 

b.  Transitions  technology  to  current  and  future  systems  to  improve 
operational  capability,  readiness,  and  supportability; 

c.  Provides  a  full  range  of  technical  support  to  Air  Force  Material 
Command  product  centers  and  other  Air  Force  organizations; 

d.  Promotes  transfer  of  technology  to  the  private  sector; 

e.  Maintains  leading  edge  technological  expertise  in  the  areas  of 
surveillance,  communications,  command  and  control,  intelligence, 
reliability  science,  electro-magnetic  technology,  photonics,  signal 
processing,  and  computational  science. 

The  thrust  areas  of  technical  competence  include:  Surveillance, 
Communications,  Command  and  Control,  Intelligence,  Signal  Processing, 
Computer  Science  and  Technology,  Electromagnetic  Technology, 
Photonics  and  Reliability  Sciences. 


